[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 771 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/771/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.MathExpressionTest.testMultiVariateNormalDistribution Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([B23FB1D1571F1061:28C438A66036526A]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.stream.MathExpressionTest.testMultiVariateNormalDistribution(MathExpressionTest.java:3010) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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) Build Log: [...truncated 15931 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-solrj/test/J1/tem
[JENKINS-EA] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-11-ea+24) - Build # 71 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/71/ Java: 64bit/jdk-11-ea+24 -XX:+UseCompressedOops -XX:+UseParallelGC 71 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 1) Thread[id=1649, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeJettyTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 1) Thread[id=1649, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeJettyTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834) at __randomizedtesting.SeedInfo.seed([50E47FC8D67F54E9]:0) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest Error Message: 14 threads leaked from SUITE scope at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest: 1) Thread[id=728, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)2) Thread[id=2076, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)3) Thread[id=720, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)4) Thread[id=2079, name=zkConnectionManagerCallback-982-thread-1, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054) at java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114) at java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)5) Thread[id=716, name=TEST-StreamDecoratorTest.testExecutorStream-seed#[50E47FC8D67F54E9]-EventThread, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)6) Thread[id=727, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)7) Thread[id=721, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11-ea/java.lang.Thread.run(Thread.java:834)8) Thread[id=2083, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(I
[jira] [Commented] (SOLR-12494) Migration documentation
[ https://issues.apache.org/jira/browse/SOLR-12494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560626#comment-16560626 ] Ana commented on SOLR-12494: Many thanks for your reply! I will do so. Regards, Ana On Fri, Jul 27, 2018 at 7:48 PM, Alexandre Rafalovitch (JIRA) < -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. > Migration documentation > > > Key: SOLR-12494 > URL: https://issues.apache.org/jira/browse/SOLR-12494 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 6.4.2 > Environment: Stage >Reporter: Ana >Priority: Trivial > > I have the following scenario, I'm having a shared cluster solr installation > environment (app server 1-app server 2 load balanced) which has 4 solr > instances. > > After reviewing the space audit we have noticed that the partition where the > installation resides is too big versus what is used in term of space. > > Therefore we have installed a new drive which is smaller and now we want to > migrate from the old dive (E:) to the new drive (F). > > Can you please provide an official answer whether this is a supported > scenario? > > If yes, will you please share the steps with us? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #426: SOLR-12595: CloudSolrClient.Builder accepts Z...
Github user vpranckaitis commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/426#discussion_r205932897
--- Diff:
solr/solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrClientBuilderTest.java
---
@@ -63,22 +66,20 @@ public void testSeveralZkHostsSpecifiedSingly() throws
IOException {
}
@Test
- public void testSeveralZkHostsSpecifiedTogether() throws IOException {
--- End diff --
This test was exactly the same as the one above, just with differently
formatted newlines.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #426: SOLR-12595: CloudSolrClient.Builder accepts Z...
GitHub user vpranckaitis opened a pull request: https://github.com/apache/lucene-solr/pull/426 SOLR-12595: CloudSolrClient.Builder accepts ZK connection strings Added additional constructor to `CloudSolrClient.Builder` which accepts ZooKeeper connection strings. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vpranckaitis/lucene-solr SOLR-12595_cloud_solr_client_builder_constructor Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/426.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #426 commit 2551b9d917c2ceb23cf16567f16870ceef725ba7 Author: Vilius Pranckaitis Date: 2018-07-28T04:40:36Z SOLR-12595: CloudSolrClient.Builder accepts ZK connection strings --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 704 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/704/
3 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTriggerRestoreState
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException:
org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error in command payload,
errors: [{suspend-trigger={name=.scheduled_maintenance}, errorMessages=[No
trigger exists with name: .scheduled_maintenance]}],
Stack Trace:
java.io.IOException: java.util.concurrent.ExecutionException:
java.io.IOException: org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error
in command payload, errors: [{suspend-trigger={name=.scheduled_maintenance},
errorMessages=[No trigger exists with name: .scheduled_maintenance]}],
at
__randomizedtesting.SeedInfo.seed([56902F8401F2D51A:7D6FFADF9B8AC0CA]:0)
at
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.request(SimCloudManager.java:632)
at
org.apache.solr.cloud.autoscaling.sim.SimCloudManager$1.request(SimCloudManager.java:211)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.setupTest(TestTriggerIntegration.java:123)
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:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.ran
[jira] [Commented] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)
[ https://issues.apache.org/jira/browse/SOLR-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560599#comment-16560599 ] jefferyyuan commented on SOLR-12477: Thanks [~varunthacker] Addressed the comments in github and changed the code as you suggested : ) > Return server error(500) for AlreadyClosedException instead of client > Errors(400) > - > > Key: SOLR-12477 > URL: https://issues.apache.org/jira/browse/SOLR-12477 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update >Reporter: jefferyyuan >Assignee: Varun Thacker >Priority: Minor > Labels: update > Fix For: 7.3.2, master (8.0) > > Time Spent: 40m > Remaining Estimate: 0h > > In some cases(for example: corrupt index), addDoc0 throws > AlreadyClosedException, but solr server returns client error 400 to client > This will confuse customers and especially monitoring tool. > Patch: [https://github.com/apache/lucene-solr/pull/402] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #402: SOLR-12477 - Return server error(500) for Alr...
Github user jefferyyuan commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/402#discussion_r205932118
--- Diff:
solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java ---
@@ -208,14 +208,17 @@ public void handleRequest(SolrQueryRequest req,
SolrQueryResponse rsp) {
}
}
} catch (Exception e) {
+ boolean hasTragicException = false;
--- End diff --
@vthacker
Changed the code as you suggested, and like you variable name: isTragic :)
I checked the code is one of 500 or 404 in LeaderTragicEventTest.java for
update or commit:
```java
assertThat(se.code(), anyOf(is(500), is(404)));
```
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12595) CloudSolrClient.Builder should accept a zkHost connection string
[
https://issues.apache.org/jira/browse/SOLR-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vilius Pranckaitis updated SOLR-12595:
--
Component/s: SolrJ
> CloudSolrClient.Builder should accept a zkHost connection string
>
>
> Key: SOLR-12595
> URL: https://issues.apache.org/jira/browse/SOLR-12595
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.4
>Reporter: Vilius Pranckaitis
>Priority: Minor
>
> SOLR-11629 improved {{CloudSolrClient.Builder}} workflow by adding two new
> constructors:
> {code:java}
> 1. public Builder(List solrUrls) {
> 2. public Builder(List zkHosts, Optional zkChroot) {
> {code}
> It is not unusual to format ZooKeeper connection details as a single string
> (e.g. {{zk1:2181,zk2:2181/some_chroot}}). However, these new constructors
> make it difficult to use such connection strings.
> It would be fairly simple to add a third constructor which would accept a
> connection string:
> {code:java}
> 3. public Builder(String zkHost) {
> {code}
> {{CloudSolrClient.Builder}} uses ZooKeeper details to construct a
> {{ZkClientClusterStateProvider}}, which [already supports ZK connection
> strings|https://github.com/apache/lucene-solr/blob/d87ea6b1ccd28e0dd8e30565fe95b2e0a31f82e8/solr/solrj/src/java/org/apache/solr/client/solrj/impl/ZkClientClusterStateProvider.java#L57-L59].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12595) CloudSolrClient.Builder should accept a zkHost connection string
[
https://issues.apache.org/jira/browse/SOLR-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vilius Pranckaitis updated SOLR-12595:
--
Affects Version/s: 7.4
> CloudSolrClient.Builder should accept a zkHost connection string
>
>
> Key: SOLR-12595
> URL: https://issues.apache.org/jira/browse/SOLR-12595
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.4
>Reporter: Vilius Pranckaitis
>Priority: Minor
>
> SOLR-11629 improved {{CloudSolrClient.Builder}} workflow by adding two new
> constructors:
> {code:java}
> 1. public Builder(List solrUrls) {
> 2. public Builder(List zkHosts, Optional zkChroot) {
> {code}
> It is not unusual to format ZooKeeper connection details as a single string
> (e.g. {{zk1:2181,zk2:2181/some_chroot}}). However, these new constructors
> make it difficult to use such connection strings.
> It would be fairly simple to add a third constructor which would accept a
> connection string:
> {code:java}
> 3. public Builder(String zkHost) {
> {code}
> {{CloudSolrClient.Builder}} uses ZooKeeper details to construct a
> {{ZkClientClusterStateProvider}}, which [already supports ZK connection
> strings|https://github.com/apache/lucene-solr/blob/d87ea6b1ccd28e0dd8e30565fe95b2e0a31f82e8/solr/solrj/src/java/org/apache/solr/client/solrj/impl/ZkClientClusterStateProvider.java#L57-L59].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-9.0.4) - Build # 71 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/71/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 13 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([8A6F0B459C2BB26:5B1FB204BBD32EDC]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:429) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds Error Message: failed to create testMixedBounds_collection Live Nodes: [127.0.0.1:10003_solr, 127.0.0.1:10002_solr] Last available state: DocCollection(testMixedBounds_collection//clus
[jira] [Updated] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-12574:
-
Attachment: (was: SOLR-12574.patch)
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-12574:
-
Attachment: SOLR-12574.patch
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch, SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 271 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/271/ No tests ran. Build Log: [...truncated 23044 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2232 links (1787 relative) to 3011 anchors in 229 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes -dist-keys: [get] Getting: http://home.apache.org/keys/group/lucene.asc [get] To: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.5.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:con
[jira] [Assigned] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch reassigned SOLR-12574:
Assignee: Alexandre Rafalovitch
Attachment: SOLR-12574.patch
Patch grouping all keys under common parents and removing redundant resultCount.
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[ https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560568#comment-16560568 ] Cao Manh Dat commented on SOLR-12412: - Hi [~varunthacker] , 1st question: this is the only way to avoid the cache of the directory and trigger merge reliable -> tragic event will reliably occur. You can try to change the code to your strategy and valid that tragic event, in that case, won't occur reliably. 2nd: Yeah, I plan to do that, but too busy with other stuff and it only makes the test less clear. not affect the case I want to test. That comment mean, we won't be able to recover shard to come active, since the leader is already corrupted hence the replica won't be able to do recovery. > Leader should give up leadership when IndexWriter.tragedy occur > --- > > Key: SOLR-12412 > URL: https://issues.apache.org/jira/browse/SOLR-12412 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-12412.patch, SOLR-12412.patch, > jenkins-failure-2325.log > > > When a leader meets some kind of unrecoverable exception (ie: > CorruptedIndexException). The shard will go into the readable state and human > has to intervene. > In that case, if there are another active replica in the same shard, the > leader should give up its leadership. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 720 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/720/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180727163617300, index.20180727163643114, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180727163617300, index.20180727163643114, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([2CD38D52C1936A45:F7788D94C4BB03F6]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:969) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:940) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:916) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakContro
[jira] [Commented] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)
[ https://issues.apache.org/jira/browse/SOLR-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560555#comment-16560555 ] Varun Thacker commented on SOLR-12477: -- Hi Jeffery, I've left one comment on the PR. Otherwise patch is looking good. > Return server error(500) for AlreadyClosedException instead of client > Errors(400) > - > > Key: SOLR-12477 > URL: https://issues.apache.org/jira/browse/SOLR-12477 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update >Reporter: jefferyyuan >Assignee: Varun Thacker >Priority: Minor > Labels: update > Fix For: 7.3.2, master (8.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > In some cases(for example: corrupt index), addDoc0 throws > AlreadyClosedException, but solr server returns client error 400 to client > This will confuse customers and especially monitoring tool. > Patch: [https://github.com/apache/lucene-solr/pull/402] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #402: SOLR-12477 - Return server error(500) for Alr...
Github user vthacker commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/402#discussion_r205929735
--- Diff:
solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java ---
@@ -208,14 +208,17 @@ public void handleRequest(SolrQueryRequest req,
SolrQueryResponse rsp) {
}
}
} catch (Exception e) {
+ boolean hasTragicException = false;
--- End diff --
Looking at LeaderTragicEventTest.java maybe we should check if the code is
a 500 or a 404 also?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 273 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/273/ 1 tests failed. FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at __randomizedtesting.SeedInfo.seed([1B491B1528671D5C:9C1E669AB93E61DC]:0) at java.util.Arrays.copyOf(Arrays.java:3181) at java.util.ArrayList.grow(ArrayList.java:265) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231) at java.util.ArrayList.add(ArrayList.java:462) at org.apache.lucene.geo.GeoTestUtil.surpriseMePolygon(GeoTestUtil.java:504) at org.apache.lucene.geo.GeoTestUtil.nextPolygon(GeoTestUtil.java:390) at org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:126) at org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig(TestLatLonShapeQueries.java:106) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) Build Log: [...truncated 10048 lines...] [junit4] Suite: org.apache.lucene.document.TestLatLonShapeQueries [junit4] 2> NOTE: download the large Jenkins line-docs file by running 'ant get-jenkins-line-docs' in the lucene directory. [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestLatLonShapeQueries -Dtests.method=testRandomBig -Dtests.seed=1B491B1528671D5C -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.locale=tr -Dtests.timezone=Asia/Samarkand -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] ERROR156s J0 | TestLatLonShapeQueries.testRandomBig <<< [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap space [junit4]>at __randomizedtesting.SeedInfo.seed([1B491B1528671D5C:9C1E669AB93E61DC]:0) [junit4]>at java.util.Arrays.copyOf(Arrays.java:3181) [junit4]>at java.util.ArrayList.grow(ArrayList.java:265) [junit4]>at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239) [junit4]>at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231) [junit4]>at java.util.ArrayList.add(ArrayList.java:462) [junit4]>at org.apache.lucene.geo.GeoTestUtil.surpriseMePolygon(GeoTestUtil.java:504) [junit4]>at org.apache.lucene.geo.GeoTestUtil.nextPolygon(GeoTestUtil.java:390) [junit4]>at org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:126) [junit4]>
[GitHub] lucene-solr pull request #402: SOLR-12477 - Return server error(500) for Alr...
Github user vthacker commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/402#discussion_r205929654
--- Diff:
solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java ---
@@ -208,14 +208,17 @@ public void handleRequest(SolrQueryRequest req,
SolrQueryResponse rsp) {
}
}
} catch (Exception e) {
+ boolean hasTragicException = false;
--- End diff --
Here is what I was thinking of after this statement. What do you think?
if (isTragic) {
if (e instanceof SolrException) {
assert ((SolrException) e).code() == 500; //Tragic exceptions
should always throw a server error
} else {
//wrap it in a solr exception
e = new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
}
}
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1065 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1065/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1079/consoleText [repro] Revision: d78feb22361cef5323793fdff33de621320d7b4b [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=TestPKIAuthenticationPlugin -Dtests.method=test -Dtests.seed=9587B35CDE436AAA -Dtests.multiplier=2 -Dtests.locale=vi -Dtests.timezone=Africa/Sao_Tome -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestTriggerIntegration -Dtests.method=testNodeLostTriggerRestoreState -Dtests.seed=9587B35CDE436AAA -Dtests.multiplier=2 -Dtests.locale=ar-DZ -Dtests.timezone=America/Kralendijk -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 828d2815f1cff7504fd3bdc0376367f737c5166c [repro] git fetch [repro] git checkout d78feb22361cef5323793fdff33de621320d7b4b [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestTriggerIntegration [repro] TestPKIAuthenticationPlugin [repro] ant compile-test [...truncated 3316 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestTriggerIntegration|*.TestPKIAuthenticationPlugin" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=9587B35CDE436AAA -Dtests.multiplier=2 -Dtests.locale=ar-DZ -Dtests.timezone=America/Kralendijk -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 9381 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.security.TestPKIAuthenticationPlugin [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration [repro] git checkout 828d2815f1cff7504fd3bdc0376367f737c5166c [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10.0.1) - Build # 7451 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7451/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestBadConfig Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestBadConfig_EED8CFC6EA35-001 at __randomizedtesting.SeedInfo.seed([EED8CFC6EA35]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java: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.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.handler.component.InfixSuggestersTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.InfixSuggestersTest_EED8CFC6EA35-001 at __randomizedtesting.SeedInfo.seed([EED8CFC6EA35]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java
[jira] [Commented] (SOLR-12477) Return server error(500) for AlreadyClosedException instead of client Errors(400)
[ https://issues.apache.org/jira/browse/SOLR-12477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560517#comment-16560517 ] jefferyyuan commented on SOLR-12477: thanks [~varunthacker] Changed CoreContainer.checkTragicException(SolrCore) to return true when there was a tragic exception. Please check the pr: [https://github.com/apache/lucene-solr/pull/402/files] Thanks. > Return server error(500) for AlreadyClosedException instead of client > Errors(400) > - > > Key: SOLR-12477 > URL: https://issues.apache.org/jira/browse/SOLR-12477 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update >Reporter: jefferyyuan >Assignee: Varun Thacker >Priority: Minor > Labels: update > Fix For: 7.3.2, master (8.0) > > Time Spent: 10m > Remaining Estimate: 0h > > In some cases(for example: corrupt index), addDoc0 throws > AlreadyClosedException, but solr server returns client error 400 to client > This will confuse customers and especially monitoring tool. > Patch: [https://github.com/apache/lucene-solr/pull/402] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2430 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2430/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild Error Message: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException Stack Trace: java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException at __randomizedtesting.SeedInfo.seed([9FD2CB2FE98EF523:405FA990D7E7A041]:0) at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: junit.framework.AssertionFailedError: Unexpected wrapped exc
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560446#comment-16560446 ] Michael Braun commented on LUCENE-8434: --- Definitely makes sense - appreciate the clarification! > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[
https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560438#comment-16560438
]
Varun Thacker commented on SOLR-12412:
--
Hi Dat,
Checking again with the doubts that I had regarding this test
First question
{quote}I'm trying to understand the corruptLeader() method : Why are we trying
to delete segment files after every add ? What if we just add the 100 docs and
then delete the segments_N file ?
{quote}
Second question
{quote}Should we start the otherReplicaJetty and then check if the leader
doesn't change in the test i.e reverse the order here ?
{quote}
The reason I ask this again is to me what's the point of starting the jetty and
putting a code comment that the shard won't be able to do anything without
actually validating it?
{code:java}
if (otherReplicaJetty != null) {
// won't be able to do anything here, since this replica can't recovery from
the leader
otherReplicaJetty.start();
}{code}
> Leader should give up leadership when IndexWriter.tragedy occur
> ---
>
> Key: SOLR-12412
> URL: https://issues.apache.org/jira/browse/SOLR-12412
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12412.patch, SOLR-12412.patch,
> jenkins-failure-2325.log
>
>
> When a leader meets some kind of unrecoverable exception (ie:
> CorruptedIndexException). The shard will go into the readable state and human
> has to intervene.
> In that case, if there are another active replica in the same shard, the
> leader should give up its leadership.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560407#comment-16560407 ] Uwe Schindler commented on LUCENE-8434: --- As Hoss said, the exception is cheaper for the uncommon case. Checking a return value in hundreds of million hits is way more expensive than a trap. The stack trace costs something but it's still cheaper. One example is MMapDirectory. One could check for correct bounds everytime but the chance to hit a boundary where you have to switch the bytebuffers is extremely low. The additional check would slow down dramatically. Have fun with reading ByteBufferIndexInput about that. We can only get rid of it with minimum required version java 9, where hotspot can eliminate double check using the new checkIndex() intrinsic in java.util.Objects > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[
https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560400#comment-16560400
]
Hoss Man commented on LUCENE-8434:
--
bq. ... It could have been represented as part of a return value that clients
would need to deal with as opposed to a RuntimeException they'd need to catch.
IIRC: there have been multiple dicussions over the years about the possibility
of {{collect(...)}} having a return value, but since the common case is to keep
collecting, the need for IndexSearcher to explicitly check the return value on
every call to {{collect}} was prohibitive in terms of performance (compared to
just catching CollectionTerminatedException).
> Use shared instance of CollectionTerminatedException
>
>
> Key: LUCENE-8434
> URL: https://issues.apache.org/jira/browse/LUCENE-8434
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
>
> Creating exceptions and filling in the stack is expensive (see SOLR-11242 and
> SOLR-11314 for two such examples). CollectionTerminatedException is used as a
> signaling mechanism - there are zero instances in code that actually log that
> it occurred or make use of anything other than the fact that it occurred
> (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions
> really should be for something exceptional - the use of
> CollectionTerminatedException is in place of polluting return values with
> this condition and is just used as a signal to callers.
> Because CollectionTerminatedException is never inspected directly and is
> effectively a different return condition, it doesn't make as much sense to
> generate new Exceptions with fresh stack traces every time - either change
> the signatures or share the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[
https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560395#comment-16560395
]
Hoss Man commented on LUCENE-8434:
--
would it make sense to support setting a sentinel exception as an expert level
option on Collectors that currently {{throw new CollectionTerminatedException}}
?
(for users who generally want {{-XX:-OmitStackTraceInFastThrow}} but in this
specific case don't care)
ie...
{code:java}
private CollectionTerminatedException reusableCollectionTerminatedException =
null;
public void
setReusableCollectionTerminatedException(CollectionTerminatedException e) {
this.reusableCollectionTerminatedException = e;
}
...
if (someConditionThatAllowsEarlyTermination) {
throw (null != reusableCollectionTerminatedException) ?
reusableCollectionTerminatedException : new
CollectionTerminatedException();
}
}
{code}
?
> Use shared instance of CollectionTerminatedException
>
>
> Key: LUCENE-8434
> URL: https://issues.apache.org/jira/browse/LUCENE-8434
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
>
> Creating exceptions and filling in the stack is expensive (see SOLR-11242 and
> SOLR-11314 for two such examples). CollectionTerminatedException is used as a
> signaling mechanism - there are zero instances in code that actually log that
> it occurred or make use of anything other than the fact that it occurred
> (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions
> really should be for something exceptional - the use of
> CollectionTerminatedException is in place of polluting return values with
> this condition and is just used as a signal to callers.
> Because CollectionTerminatedException is never inspected directly and is
> effectively a different return condition, it doesn't make as much sense to
> generate new Exceptions with fresh stack traces every time - either change
> the signatures or share the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560393#comment-16560393 ] Michael Braun commented on LUCENE-8434: --- Thanks [~thetaphi] - did not know about the OmitStackTraceInFastThrow optimization! When I have some free time I'll look to see if this is kicking in for all practical cases. In general though, as to using a RuntimeException as an alternative to adjusting signatures - where has the balance been found between representing an alternate scenario with an Exception versus a representative return value containing that it happened? It could have been represented as part of a return value that clients would need to deal with as opposed to a RuntimeException they'd need to catch. > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560391#comment-16560391 ] Uwe Schindler commented on LUCENE-8434: --- - https://stackoverflow.com/questions/33241012/can-hotspot-jit-optimizations-for-fast-throw-exceptions-lead-to-ambiguous-result - http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-lose-their-stack-traces-in-production-and-the-fix/ > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560376#comment-16560376 ] Uwe Schindler commented on LUCENE-8434: --- bq. It might be expensive at the beginning, but stack trace creation should be suppressed by the JVM if the trace is not used (at least if all of it happens in one single class and not through several stack frames). The optimization needs some time until it jumps in, so simple tests executed only one or two times don't help for measuring this. > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
[ https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560374#comment-16560374 ] Uwe Schindler commented on LUCENE-8434: --- -1, see other issue LUCENE-8432! > Use shared instance of CollectionTerminatedException > > > Key: LUCENE-8434 > URL: https://issues.apache.org/jira/browse/LUCENE-8434 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > Creating exceptions and filling in the stack is expensive (see SOLR-11242 and > SOLR-11314 for two such examples). CollectionTerminatedException is used as a > signaling mechanism - there are zero instances in code that actually log that > it occurred or make use of anything other than the fact that it occurred > (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions > really should be for something exceptional - the use of > CollectionTerminatedException is in place of polluting return values with > this condition and is just used as a signal to callers. > Because CollectionTerminatedException is never inspected directly and is > effectively a different return condition, it doesn't make as much sense to > generate new Exceptions with fresh stack traces every time - either change > the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560371#comment-16560371
]
Uwe Schindler commented on LUCENE-8432:
---
I agree with Robert. It might be expensive at the beginning, but stack trace
creation should be suppressed by the JVM if the trace is not used (at least if
all of it happens in one single class and not through several stack frames).
The optimization needs some time until it jumps in, so simple tests executed
only one or two times don't help for measuring this,.
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> OrHighNotMed 87.06 (3.7%) 87.80 (4.1%)
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560372#comment-16560372
]
Michael Braun commented on LUCENE-8432:
---
Added LUCENE-8434 with this to not pollute the comments here, agree on
debugging on [~rcmuir] but don't believe it applies here, feel free to continue
discussion there!
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> OrHighNotMed 87.06 (3.7%) 87.80 (4.1%)
> 0.8% ( -6% - 8%)
> IntNRQ 26.44 (12.8%) 26.68 (11.5%)
> 0.9% ( -20% - 28%)
> HighTerm 107.64 (6.1%) 108.88 (5.
[jira] [Created] (LUCENE-8434) Use shared instance of CollectionTerminatedException
Michael Braun created LUCENE-8434: - Summary: Use shared instance of CollectionTerminatedException Key: LUCENE-8434 URL: https://issues.apache.org/jira/browse/LUCENE-8434 Project: Lucene - Core Issue Type: Improvement Reporter: Michael Braun Creating exceptions and filling in the stack is expensive (see SOLR-11242 and SOLR-11314 for two such examples). CollectionTerminatedException is used as a signaling mechanism - there are zero instances in code that actually log that it occurred or make use of anything other than the fact that it occurred (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions really should be for something exceptional - the use of CollectionTerminatedException is in place of polluting return values with this condition and is just used as a signal to callers. Because CollectionTerminatedException is never inspected directly and is effectively a different return condition, it doesn't make as much sense to generate new Exceptions with fresh stack traces every time - either change the signatures or share the object. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560370#comment-16560370 ] ASF subversion and git services commented on SOLR-12599: Commit bde2f2a548deff5808b0f45f446bbc1d8ffaca78 in lucene-solr's branch refs/heads/branch_7x from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bde2f2a ] SOLR-12599: Add more query routing params to the ref guide (cherry picked from commit 828d281) > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560369#comment-16560369 ] ASF subversion and git services commented on SOLR-12599: Commit 828d2815f1cff7504fd3bdc0376367f737c5166c in lucene-solr's branch refs/heads/master from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=828d281 ] SOLR-12599: Add more query routing params to the ref guide > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1079 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1079/ No tests ran. Build Log: [...truncated 22996 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of sequence: expected level 4, got level 5 [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of sequence: expected level 2, got level 3 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of sequence: expected level 2, got level 3 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of sequence: expected level 2, got level 3 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of sequence: expected level 2, got level 3 [asciidoctor:convert] asciidoctor: WARNING: solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of sequence: expected level 2, got level 3 [java] Processed 2244 links (1798 relative) to 3136 anchors in 246 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes -dist-keys: [get] Getting: http://home.apache.org/keys/group/lucene.asc [get] To: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-S
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560333#comment-16560333
]
Robert Muir commented on LUCENE-8432:
-
i am strongly opposed to this in lucene code. we must be able to debug stuff.
wrong tradeoff in all cases!
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> OrHighNotMed 87.06 (3.7%) 87.80 (4.1%)
> 0.8% ( -6% - 8%)
> IntNRQ 26.44 (12.8%) 26.68 (11.5%)
> 0.9% ( -20% - 28%)
> HighTerm 107.64 (6.1%) 108.88 (5.6%)
> 1.2% ( -9% - 13%)
> Fuzzy2 69.6
[jira] [Commented] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-12572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560194#comment-16560194
]
Lucene/Solr QA commented on SOLR-12572:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
14s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 39m
5s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 43m 24s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12572 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933379/SOLR-12572.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 1888bb5 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/154/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/154/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch,
> SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query&sort=severity+desc,timestamp+desc&fl=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example
> 'severity, 'timestamp'). When we stream out docs we again make doc-value
> seeks against the {{fl}} fields ('severity','timestamp','msg') .
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values
> while sorting it, we can reduce the doc-value seeks potentially bringing
> *speed improvement*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560154#comment-16560154 ] Varun Thacker commented on SOLR-12599: -- Small update to the previous patch which adds more information around document routing > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-12599: - Attachment: SOLR-12599.patch > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12055) Enable asynch logging by default
[
https://issues.apache.org/jira/browse/SOLR-12055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560152#comment-16560152
]
Varun Thacker commented on SOLR-12055:
--
{quote}We def want to change it to async for tests at minimum - with many Solr
instances often logging and all going through the same sync block, it's rather
nasty with lots of blocking.
{quote}
I tried doing this on my system and when I used the async logger all solr tests
completed in 38 mins vs 42 minutes.
There was an assert in TestLogWatcher that failed which we might have to fix if
we go async for tests.
To switch to the async logger I imply changed the {{Root}} tag to be
{{AsyncRoot}}
Curious if others see less or more gains while running tests
> Enable asynch logging by default
>
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change
> to the config files for log4j2. This will reduce contention and increase
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here:
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async
> logging.
> I guess even if we enable async by default the ref guide still needs a note
> about how to _disable_ it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 108 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/108/ 2 tests failed. FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes Error Message: unexpected shard state expected: but was: Stack Trace: java.lang.AssertionError: unexpected shard state expected: but was: at __randomizedtesting.SeedInfo.seed([B313B689A5B100E2:BD0E229596AD597]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.cloud.api.collections.ShardSplitTest.verifyShard(ShardSplitTest.java:380) at org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitMixedReplicaTypes(ShardSplitTest.java:372) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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)
[jira] [Commented] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560130#comment-16560130 ] Varun Thacker commented on SOLR-12599: -- Decided to just take the information from that page and add it to an existing page This is a good start already as users won't even know about these parameters otherwise. I think we can make progress here by committing this rather then striving for perfection ( beefing up debug=track etc ) > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-12599: - Attachment: SOLR-12599.patch > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-12599.patch, > advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12590) Improve Solr resource loader coverage in the ref guide
[
https://issues.apache.org/jira/browse/SOLR-12590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560124#comment-16560124
]
Steve Rowe commented on SOLR-12590:
---
{quote}
bq. Under SolrCloud, resources to be loaded are first looked up in ZooKeeper
under the collection's configset znode. If the resource isn't found there, Solr
will fall back to loading resources from the filesystem.
A nicely concise and clear lead paragraph, I like it. Side question: was this
fallback logic 'always' there (and I just didn't know about it, oops) or is it
something introduced in a recent-ish version?
{quote}
I think it's always been there. The comment below (positioned after failing to
load a resource from ZooKeeper), dates to 2010, when SolrCloud was committed to
Subversion trunk (SOLR-1873):
{code:java|title=ZkZolrResourceLoader.openResource() (branch_7x)}
121:try {
122: // delegate to the class loader (looking into $INSTANCE_DIR/lib jars)
123: is =
classLoader.getResourceAsStream(resource.replace(File.separatorChar, '/'));
{code}
bq. So yes, if the wrapper model concept is not or no longer needed then let's
not mention it in the documentation.
Do you have the bandwidth to test this assertion? I'd rather not remove docs
unless we can verify the alternative.
> Improve Solr resource loader coverage in the ref guide
> --
>
> Key: SOLR-12590
> URL: https://issues.apache.org/jira/browse/SOLR-12590
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12590.patch
>
>
> In SolrCloud, storing large resources (e.g. binary machine learned models) on
> the local filesystem should be a viable alternative to increasing ZooKeeper's
> max file size limit (1MB), but there are undocumented complications.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12590) Improve Solr resource loader coverage in the ref guide
[ https://issues.apache.org/jira/browse/SOLR-12590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560103#comment-16560103 ] Christine Poerschke commented on SOLR-12590: bq. ... added info about how the resource loader works. ... the learning-to-rank large model discussion to point to local storage as an alternative, but I think it should be applicable; I haven't tried myself. ... is it possible that that indirection is not necessary? Good question. In your patch the "Resources in ConfigSets on ZooKeeper" lead paragraph is: bq. Under SolrCloud, resources to be loaded are first looked up in ZooKeeper under the collection's configset znode. If the resource isn't found there, Solr will fall back to loading resources from the filesystem. A nicely concise and clear lead paragraph, I like it. Side question: was this fallback logic 'always' there (and I just didn't know about it, oops) or is it something introduced in a recent-ish version? Either way, if the documentation provides one recommended way of doing things that should be clearest from a user's point of view. So yes, if the wrapper model concept is not or no longer needed then let's not mention it in the documentation. > Improve Solr resource loader coverage in the ref guide > -- > > Key: SOLR-12590 > URL: https://issues.apache.org/jira/browse/SOLR-12590 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Major > Attachments: SOLR-12590.patch > > > In SolrCloud, storing large resources (e.g. binary machine learned models) on > the local filesystem should be a viable alternative to increasing ZooKeeper's > max file size limit (1MB), but there are undocumented complications. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-12599: - Attachment: advanced-distributed-request-options.adoc > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12599) Add search routing documentation
[ https://issues.apache.org/jira/browse/SOLR-12599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560088#comment-16560088 ] Varun Thacker commented on SOLR-12599: -- I've attached the original page. i'll do a quick review and post an updated patch shortly. > Add search routing documentation > > > Key: SOLR-12599 > URL: https://issues.apache.org/jira/browse/SOLR-12599 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: advanced-distributed-request-options.adoc > > > The old ref guide used to have a very good page which was always unpublished > about search routing. > Yesterday I wanted to point a user to it and then realized it's not present > in the new ref guide . Cassandra pointed out offline that she has a copy of > this page which was never added to the new ref guide because they weren't > published ever. > We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12599) Add search routing documentation
Varun Thacker created SOLR-12599: Summary: Add search routing documentation Key: SOLR-12599 URL: https://issues.apache.org/jira/browse/SOLR-12599 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Varun Thacker The old ref guide used to have a very good page which was always unpublished about search routing. Yesterday I wanted to point a user to it and then realized it's not present in the new ref guide . Cassandra pointed out offline that she has a copy of this page which was never added to the new ref guide because they weren't published ever. We should review this page and add it to the ref guide -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+24) - Build # 22541 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22541/ Java: 64bit/jdk-11-ea+24 -XX:-UseCompressedOops -XX:+UseSerialGC 10 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledTriggerIntegrationTest.testScheduledTrigger Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([2361CFB91134F445:B07A87CB4FC9AF71]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.autoscaling.ScheduledTriggerIntegrationTest.testScheduledTrigger(ScheduledTriggerIntegrationTest.java:114) 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:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.cloud.autoscaling.ScheduledTriggerIntegrationTest.testSche
[GitHub] lucene-solr pull request #416: WIP: SOLR-12519
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/416#discussion_r205851891
--- Diff:
solr/core/src/test/org/apache/solr/response/transform/TestDeeplyNestedChildDocTransformer.java
---
@@ -0,0 +1,227 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.response.transform;
+
+import java.util.Iterator;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import com.google.common.collect.Iterables;
+import org.apache.lucene.document.StoredField;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.SolrDocument;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.BasicResultContext;
+import org.junit.After;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+public class TestDeeplyNestedChildDocTransformer extends SolrTestCaseJ4 {
+
+ private static AtomicInteger counter = new AtomicInteger();
+ private static final char PATH_SEP_CHAR = '/';
+ private static final String[] types = {"donut", "cake"};
+ private static final String[] ingredients = {"flour", "cocoa",
"vanilla"};
+ private static final Iterator ingredientsCycler =
Iterables.cycle(ingredients).iterator();
+ private static final String[] names = {"Yaz", "Jazz", "Costa"};
+
+ @BeforeClass
+ public static void beforeClass() throws Exception {
+initCore("solrconfig-update-processor-chains.xml", "schema15.xml");
+ }
+
+ @After
+ public void after() throws Exception {
+assertU(delQ("*:*"));
+assertU(commit());
+counter.set(0); // reset id counter
+ }
+
+ @Test
+ public void testParentFilterJSON() throws Exception {
+indexSampleData(10);
+String[] tests = new String[] {
+"/response/docs/[0]/type_s==[donut]",
+"/response/docs/[0]/toppings/[0]/type_s==[Regular]",
+"/response/docs/[0]/toppings/[1]/type_s==[Chocolate]",
+"/response/docs/[0]/toppings/[0]/ingredients/[0]/name_s==[cocoa]",
+"/response/docs/[0]/toppings/[1]/ingredients/[1]/name_s==[cocoa]",
+"/response/docs/[0]/lonely/test_s==[testing]",
+"/response/docs/[0]/lonely/lonelyGrandChild/test2_s==[secondTest]",
+};
+
+try(SolrQueryRequest req = req("q", "type_s:donut", "sort", "id asc",
"fl", "*, _nest_path_, [child hierarchy=true]")) {
+ BasicResultContext res = (BasicResultContext)
h.queryAndResponse("/select", req).getResponse();
+ Iterator docsStreamer = res.getProcessedDocuments();
+ while (docsStreamer.hasNext()) {
+SolrDocument doc = docsStreamer.next();
+int currDocId = Integer.parseInt(((StoredField)
doc.getFirstValue("id")).stringValue());
+assertEquals("queried docs are not equal to expected output for
id: " + currDocId, fullNestedDocTemplate(currDocId), doc.toString());
+ }
+}
+
+assertJQ(req("q", "type_s:donut",
+"sort", "id asc",
+"fl", "*, _nest_path_, [child hierarchy=true]"),
+tests);
+ }
+
+ @Test
+ public void testExactPath() throws Exception {
+indexSampleData(2);
+String[] tests = {
+"/response/numFound==4",
+"/response/docs/[0]/_nest_path_=='toppings#0'",
+"/response/docs/[1]/_nest_path_=='toppings#0'",
+"/response/docs/[2]/_nest_path_=='toppings#1'",
+"/response/docs/[3]/_nest_path_=='toppings#1'",
+};
+
+assertJQ(req("q", "_nest_path_:*toppings/",
+"sort", "_nest_path_ asc",
+"fl", "*, _nest_path_"),
+tests);
+
+assertJQ(req("q", "+_nest_path_:\"toppings/\"",
+"sort", "_nest_path_ asc",
+"fl", "*, _nest_path_"),
+tests);
+ }
+
+ @Test
+ public void testChildFilterJSON() throws Exception {
+indexSampleData(10);
+String[] tests = new String[] {
+
Re: [JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 21 - Still Failing
Chris Lambertus rebooted lucene1-us-west.a.o, and did some light cleanup on the root partition, but there is still little free space there; in the short-term, though, Jenkins should be functional. At Chris’s request I created https://issues.apache.org/jira/browse/INFRA-16833 to free up more space. FYI lucene2-us-west.a.o (the second VM used to run ASF Jenkins jobs) did not run out of disk space. -- Steve www.lucidworks.com > On Jul 27, 2018, at 12:46 PM, Steve Rowe wrote: > > At least one of the lucene Jenkins VMs (lucene1-us-west.apache.org) has run > out of disk space. I ran ‘ant clean’ on all Jenkins workspaces. However, > the root filesystem (separate from the filesystem hosting Jenkins’s > workspaces) has run out of space, and I don’t have permissions to even look > at some of it, so I’m going to contact Infra on hipchat to see what they can > do. > > -- > Steve > www.lucidworks.com > >> On Jul 27, 2018, at 12:20 PM, Apache Jenkins Server >> wrote: >> >> Build: >> https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/21/ >> >> No tests ran. >> >> Build Log: >> [...truncated 23 lines...] >> ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/test-data >> org.tmatesoft.svn.core.SVNException: svn: E200030: FULL >> at >> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70) >> at >> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) >> at >> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) >> 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:897) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:363) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1349) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:847) >> at >> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:263) >> at >> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:115) >> at >> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40) >> at >> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) >> 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 >> org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) >> at >> org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) >> at >> org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) >> at >> hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:161) >> 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:2918) >> 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:748) >> Caused by: org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is >> FULL >> at >> org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3044) >> at >> org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2775) >> at >> org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931) >> at >> org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561) >> at >> org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.ja
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4761 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4761/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir
Error Message:
Captured an uncaught exception in thread: Thread[id=6023,
name=cdcr-replicator-1645-thread-1, state=RUNNABLE,
group=TGRP-CdcrBidirectionalTest]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=6023, name=cdcr-replicator-1645-thread-1,
state=RUNNABLE, group=TGRP-CdcrBidirectionalTest]
Caused by: java.lang.AssertionError: 1607159756928057344 != 1607159756927008768
at __randomizedtesting.SeedInfo.seed([E6D60D0225BD43B5]:0)
at
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611)
at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:105)
at
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$start$0(CdcrReplicatorScheduler.java:81)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base/java.lang.Thread.run(Thread.java:844)
Build Log:
[...truncated 12381 lines...]
[junit4] Suite: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest
[junit4] 2> 285255 INFO
(SUITE-CdcrBidirectionalTest-seed#[E6D60D0225BD43B5]-worker) []
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
[junit4] 2> Creating dataDir:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.cdcr.CdcrBidirectionalTest_E6D60D0225BD43B5-001/init-core-data-001
[junit4] 2> 285255 WARN
(SUITE-CdcrBidirectionalTest-seed#[E6D60D0225BD43B5]-worker) []
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=86 numCloses=86
[junit4] 2> 285255 INFO
(SUITE-CdcrBidirectionalTest-seed#[E6D60D0225BD43B5]-worker) []
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false)
w/NUMERIC_DOCVALUES_SYSPROP=false
[junit4] 2> 285256 INFO
(SUITE-CdcrBidirectionalTest-seed#[E6D60D0225BD43B5]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via:
@org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0,
clientAuth=0.0/0.0) w/ MAC_OS_X supressed clientAuth
[junit4] 2> 285260 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[E6D60D0225BD43B5]) []
o.a.s.SolrTestCaseJ4 ###Starting testBiDir
[junit4] 2> 285260 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[E6D60D0225BD43B5]) []
o.a.s.c.MiniSolrCloudCluster Starting cluster of 1 servers in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.cdcr.CdcrBidirectionalTest_E6D60D0225BD43B5-001/cdcr-cluster2-001
[junit4] 2> 285260 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[E6D60D0225BD43B5]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 285266 INFO (Thread-363) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 285266 INFO (Thread-363) [] o.a.s.c.ZkTestServer Starting
server
[junit4] 2> 285272 ERROR (Thread-363) [] o.a.z.s.ZooKeeperServer
ZKShutdownHandler is not registered, so ZooKeeper server won't take any action
on ERROR or SHUTDOWN server state changes
[junit4] 2> 285365 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[E6D60D0225BD43B5]) []
o.a.s.c.ZkTestServer start zk server on port:50903
[junit4] 2> 285380 INFO (zkConnectionManagerCallback-2332-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
[junit4] 2> 285457 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.Server jetty-9.4.11.v20180605; built: 2018-06-05T18:24:03.829Z; git:
d5fc0523cfa96bfebfbda19606cad384d772f04c; jvm 9+181
[junit4] 2> 285458 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.session DefaultSessionIdManager workerName=node0
[junit4] 2> 285458 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.session No SessionScavenger set, using defaults
[junit4] 2> 285458 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.session node0 Scavenging every 66ms
[junit4] 2> 285458 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@29f8f4eb{/solr,null,AVAILABLE}
[junit4] 2> 285506 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.AbstractConnector Started ServerConnector@c176e6f{SSL,[ssl,
http/1.1]}{127.0.0.1:50905}
[junit4] 2> 285506 INFO (jetty-launcher-2329-thread-1) []
o.e.j.s.Server Started @285578ms
[junit4] 2> 285506 INFO (jetty-launcher-2329-thread-1) []
o.a.s.c.s.e.Je
[jira] [Commented] (LUCENE-8418) LatLonShapeBoundingBoxQuery failure in Polygon with Hole
[
https://issues.apache.org/jira/browse/LUCENE-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560011#comment-16560011
]
ASF subversion and git services commented on LUCENE-8418:
-
Commit 50615fda9dfa13d37151baddca6bb74b5cd1eca8 in lucene-solr's branch
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=50615fd ]
LUCENE-8418: Fix tessellation failure on polygon with holes due to
vertex index clashing.
> LatLonShapeBoundingBoxQuery failure in Polygon with Hole
>
>
> Key: LUCENE-8418
> URL: https://issues.apache.org/jira/browse/LUCENE-8418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
>
> Found the following test failure while testing with a random polygon with
> hole:
> {code}
> 07:13:46[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLatLonShape -Dtests.method=testBasicIntersects
> -Dtests.seed=A8704FF5E1106095 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=ar -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
> 07:13:46[junit4] FAILURE 0.48s J0 | TestLatLonShape.testBasicIntersects
> <<<
> 07:13:46[junit4]> Throwable #1: java.lang.AssertionError:
> expected:<0> but was:<1>
> 07:13:46[junit4]> at
> __randomizedtesting.SeedInfo.seed([A8704FF5E1106095:9F0DBC00DD87C3EB]:0)
> 07:13:46[junit4]> at
> org.apache.lucene.document.TestLatLonShape.testBasicIntersects(TestLatLonShape.java:113)
> 07:13:46[junit4]> at java.lang.Thread.run(Thread.java:748)
> 07:13:46[junit4] 2> NOTE: leaving temporary files on disk at:
> /var/lib/jenkins/workspace/apache+lucene-solr+branch_7x/lucene/build/sandbox/test/J0/temp/lucene.document.TestLatLonShape_A8704FF5E1106095-001
> 07:13:46[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {}, docValues:{}, maxPointsInLeafNode=140, maxMBSortInHeap=7.774833175701376,
> sim=RandomSimilarity(queryNorm=false): {}, locale=ar,
> timezone=Europe/Amsterdam
> 07:13:46[junit4] 2> NOTE: Linux 3.16.0-4-amd64 amd64/Oracle Corporation
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=302653784,total=449314816
> 07:13:46[junit4] 2> NOTE: All tests run in this JVM: [TestLatLonShape]
> 07:13:46[junit4] Completed [18/24 (1!)] on J0 in 21.09s, 3 tests, 1
> failure, 1 skipped <<< FAILURES!
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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 # 2625 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2625/ No tests ran. Build Log: [...truncated 1935 lines...] ERROR: command execution failed. ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-Tests-master #2625 ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-Tests-master #2625 ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) Email was triggered for: Failure - Any Sending email for trigger: Failure - Any ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8418) LatLonShapeBoundingBoxQuery failure in Polygon with Hole
[
https://issues.apache.org/jira/browse/LUCENE-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560010#comment-16560010
]
ASF subversion and git services commented on LUCENE-8418:
-
Commit 1888bb5d3edfe553eb7072879f5564b7baa221cd in lucene-solr's branch
refs/heads/master from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1888bb5 ]
LUCENE-8418: Fix tessellation failure on polygon with holes due to
vertex index clashing.
> LatLonShapeBoundingBoxQuery failure in Polygon with Hole
>
>
> Key: LUCENE-8418
> URL: https://issues.apache.org/jira/browse/LUCENE-8418
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
>
> Found the following test failure while testing with a random polygon with
> hole:
> {code}
> 07:13:46[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestLatLonShape -Dtests.method=testBasicIntersects
> -Dtests.seed=A8704FF5E1106095 -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=ar -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
> 07:13:46[junit4] FAILURE 0.48s J0 | TestLatLonShape.testBasicIntersects
> <<<
> 07:13:46[junit4]> Throwable #1: java.lang.AssertionError:
> expected:<0> but was:<1>
> 07:13:46[junit4]> at
> __randomizedtesting.SeedInfo.seed([A8704FF5E1106095:9F0DBC00DD87C3EB]:0)
> 07:13:46[junit4]> at
> org.apache.lucene.document.TestLatLonShape.testBasicIntersects(TestLatLonShape.java:113)
> 07:13:46[junit4]> at java.lang.Thread.run(Thread.java:748)
> 07:13:46[junit4] 2> NOTE: leaving temporary files on disk at:
> /var/lib/jenkins/workspace/apache+lucene-solr+branch_7x/lucene/build/sandbox/test/J0/temp/lucene.document.TestLatLonShape_A8704FF5E1106095-001
> 07:13:46[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {}, docValues:{}, maxPointsInLeafNode=140, maxMBSortInHeap=7.774833175701376,
> sim=RandomSimilarity(queryNorm=false): {}, locale=ar,
> timezone=Europe/Amsterdam
> 07:13:46[junit4] 2> NOTE: Linux 3.16.0-4-amd64 amd64/Oracle Corporation
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=302653784,total=449314816
> 07:13:46[junit4] 2> NOTE: All tests run in this JVM: [TestLatLonShape]
> 07:13:46[junit4] Completed [18/24 (1!)] on J0 in 21.09s, 3 tests, 1
> failure, 1 skipped <<< FAILURES!
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559992#comment-16559992
]
Michael Braun commented on LUCENE-8432:
---
To speed this up even more, is it possible to not generate and throw new
CollectionTerminatedExceptions? Filling out the stack is expensive (see
SOLR-11242 and SOLR-11314) - if it's just used as a means of signaling without
ever inspecting, and it's a normal case that it terminated early, should this
be a static final object that gets thrown? This may be out of scope of this
jira ticket in which case I can open a new one.
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> O
[jira] [Commented] (SOLR-12494) Migration documentation
[ https://issues.apache.org/jira/browse/SOLR-12494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559986#comment-16559986 ] Alexandre Rafalovitch commented on SOLR-12494: -- Hi Ana, This case has been closed as Invalid. You were advised to use the mailing list. Yes, sometimes people do not see enough details in your email and not sure how to answer. But this would be even less the case with the JIRAs, as they are not designed for this (for Apache projects). Could you please ask again at the Solr Users mailing list and try to be as precise as possible with your setup/issues, including specific version of Solr. > Migration documentation > > > Key: SOLR-12494 > URL: https://issues.apache.org/jira/browse/SOLR-12494 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 6.4.2 > Environment: Stage >Reporter: Ana >Priority: Trivial > > I have the following scenario, I'm having a shared cluster solr installation > environment (app server 1-app server 2 load balanced) which has 4 solr > instances. > > After reviewing the space audit we have noticed that the partition where the > installation resides is too big versus what is used in term of space. > > Therefore we have installed a new drive which is smaller and now we want to > migrate from the old dive (E:) to the new drive (F). > > Can you please provide an official answer whether this is a supported > scenario? > > If yes, will you please share the steps with us? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 21 - Still Failing
At least one of the lucene Jenkins VMs (lucene1-us-west.apache.org) has run out of disk space. I ran ‘ant clean’ on all Jenkins workspaces. However, the root filesystem (separate from the filesystem hosting Jenkins’s workspaces) has run out of space, and I don’t have permissions to even look at some of it, so I’m going to contact Infra on hipchat to see what they can do. -- Steve www.lucidworks.com > On Jul 27, 2018, at 12:20 PM, Apache Jenkins Server > wrote: > > Build: > https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/21/ > > No tests ran. > > Build Log: > [...truncated 23 lines...] > ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/test-data > org.tmatesoft.svn.core.SVNException: svn: E200030: FULL > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) > 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:897) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:363) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1349) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:847) > at > org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:263) > at > org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:115) > at > org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40) > at > org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) > 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 > org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) > at > org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) > at > org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) > at > hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:161) > 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:2918) > 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:748) > Caused by: org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL > at > org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3044) > at > org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2775) > at > org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931) > at > org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561) > at > org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55) > at > org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$12.runSynchronized(SqlJetEngine.java:535) > at > org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217) > at > org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runEngineTransaction(SqlJetEngine.java:529) > at > org.tmatesoft.sqljet.core.table.SqlJetDb.runTransaction(SqlJetDb.java:238) > at > org.tmatesoft.sqljet.core.table.SqlJetDb.runWriteTransaction(SqlJetDb.java:211) > at > org.tmatesoft.svn.core.internal.
[JENKINS] Lucene-Solr-Tests-7.x - Build # 702 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/702/ 5 tests failed. FAILED: org.apache.solr.cloud.api.collections.TestReplicaProperties.test Error Message: KeeperErrorCode = Session expired for /clusterstate.json Stack Trace: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /clusterstate.json at __randomizedtesting.SeedInfo.seed([A8F36BB533F8D484:20A7546F9D04B97C]:0) at org.apache.zookeeper.KeeperException.create(KeeperException.java:130) at org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1215) at org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:341) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:341) at org.apache.solr.common.cloud.ZkStateReader.refreshLegacyClusterState(ZkStateReader.java:567) at org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:371) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.updateMappingsFromZk(AbstractFullDistribZkTestBase.java:681) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.updateMappingsFromZk(AbstractFullDistribZkTestBase.java:676) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:471) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:341) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1006) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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(TestRuleIgnoreTes
[jira] [Commented] (SOLR-10299) Provide search for online Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559984#comment-16559984 ] Alexandre Rafalovitch commented on SOLR-10299: -- It took a bit of head-scratching to realize that the options will appear on hitting the enter as opposed to the current auto-complete. More importantly, there is no feedback to evaluate the search by. It does seem to pick-up titles and text keywords much better than current implementation. It _seems_ to give boost to the titles over plain text. Maybe one thing I would add is which section the text is found in by splitting the page document into parent/child arrangement during indexing. We do have a lot of multi-topic pages. And then jump to the right page section from the screen. And/or highlighting matching text. > Provide search for online Ref Guide > --- > > Key: SOLR-10299 > URL: https://issues.apache.org/jira/browse/SOLR-10299 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Priority: Major > Attachments: basic-services-diagram.png > > > The POC to move the Ref Guide off Confluence did not address providing > full-text search of the page content. Not because it's hard or impossible, > but because there were plenty of other issues to work on. > The current HTML page design provides a title index, but to replicate the > current Confluence experience, the online version(s) need to provide a > full-text search experience. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Artifacts-7.x - Build # 263 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-7.x/263/ No tests ran. Build Log: [...truncated 7633 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/common-build.xml:847: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/core/build.xml:63: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/common-build.xml:2221: error running fixcrlf on file /x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/build/docs/core/script.js Total time: 3 minutes 23 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1056 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-repro/1056/ [...truncated 26 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1057 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-repro/1057/ [...truncated 26 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 113 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/113/ No tests ran. Build Log: [...truncated 1030 lines...] [junit4] Suite: org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormat [junit4] ERROR 0.00s J1 | TestLucene50StoredFieldsFormat (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormat [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [junit4]>at java.lang.Class.forName0(Native Method) [junit4]>at java.lang.Class.forName(Class.java:348) [junit4] Completed [230/483 (1!)] on J1 in 0.00s, 0 tests, 1 error <<< FAILURES! [...truncated 2 lines...] [junit4] Suite: org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormatHighCompression [junit4] ERROR 0.00s J1 | TestLucene50StoredFieldsFormatHighCompression (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormatHighCompression [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [junit4]>at java.lang.Class.forName0(Native Method) [junit4]>at java.lang.Class.forName(Class.java:348) [junit4] Completed [231/483 (2!)] on J1 in 0.00s, 0 tests, 1 error <<< FAILURES! [...truncated 2 lines...] [junit4] Suite: org.apache.lucene.codecs.lucene50.TestLucene50TermVectorsFormat [junit4] ERROR 0.00s J1 | TestLucene50TermVectorsFormat (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.lucene50.TestLucene50TermVectorsFormat [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [junit4]>at java.lang.Class.forName0(Native Method) [junit4]>at java.lang.Class.forName(Class.java:348) [junit4] Completed [232/483 (3!)] on J1 in 0.00s, 0 tests, 1 error <<< FAILURES! [...truncated 2 lines...] [junit4] Suite: org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat [junit4] ERROR 0.00s J1 | TestPerFieldDocValuesFormat (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [junit4]>at java.lang.Class.forName0(Native Method) [junit4]>at java.lang.Class.forName(Class.java:348) [junit4] Completed [233/483 (4!)] on J1 in 0.00s, 0 tests, 1 error <<< FAILURES! [...truncated 2 lines...] [junit4] Suite: org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat [junit4] ERROR 0.00s J1 | TestPerFieldPostingsFormat (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [junit4]>at java.lang.Class.forName0(Native Method) [junit4]>at java.lang.Class.forName(Class.java:348) [junit4] Completed [234/483 (5!)] on J1 in 0.00s, 0 tests, 1 error <<< FAILURES! [...truncated 2 lines...] [junit4] Suite: org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat2 [junit4] ERROR 0.00s J1 | TestPerFieldPostingsFormat2 (suite) <<< [junit4]> Throwable #1: java.lang.ClassNotFoundException: org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat2 [junit4]>at java.net.URLClassLoader.findClass(URLClassLoader.java:381) [junit4]>at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [junit4]>at
[JENKINS-MAVEN] Lucene-Solr-Maven-master #2309: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2309/ No tests ran. Build Log: [...truncated 8007 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:672: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:218: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:621: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:616: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:847: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/core/build.xml:63: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:2221: error running fixcrlf on file /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build/docs/core/script.js Total time: 2 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1055 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-repro/1055/ [...truncated 26 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 21 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/21/ No tests ran. Build Log: [...truncated 23 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E200030: FULL at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:760) 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:897) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:363) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1349) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:847) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:263) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:115) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) 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 org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:161) 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:2918) 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:748) Caused by: org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3044) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2775) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$12.runSynchronized(SqlJetEngine.java:535) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runEngineTransaction(SqlJetEngine.java:529) at org.tmatesoft.sqljet.core.table.SqlJetDb.runTransaction(SqlJetDb.java:238) at org.tmatesoft.sqljet.core.table.SqlJetDb.runWriteTransaction(SqlJetDb.java:211) at org.tmatesoft.svn.core.internal.wc17.db.statement.SVNWCDbCreateSchema.exec(SVNWCDbCreateSchema.java:225) at org.tmatesoft.svn.core.internal.db.SVNSqlJetStatement.done(SVNSqlJetStatement.java:420) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb$BumpRevisionPostUpdate.bumpMovedAway(SVNWCDb.java:5421) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb$BumpRevisionPostUpdate.transaction(SVNWCDb.java:5414) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:258) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransacti
[JENKINS-MAVEN] Lucene-Solr-Maven-7.x #258: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/258/ No tests ran. Build Log: [...truncated 8044 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:672: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:218: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:621: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:616: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:847: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/core/build.xml:63: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:2221: error running fixcrlf on file /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/build/docs/core/script.js Total time: 2 minutes 32 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1054 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-repro/1054/ [...truncated 26 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1053 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-repro/1053/ [...truncated 26 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-Artifacts-master - Build # 3395 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-master/3395/ No tests ran. Build Log: [...truncated 8554 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/build.xml:552: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/build.xml:456: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/test-framework/build.xml:94: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:621: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:616: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:847: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/core/build.xml:63: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:2221: error running fixcrlf on file /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/build/docs/core/script.js Total time: 3 minutes 13 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1052 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-repro/1052/ [...truncated 41 lines...] FATAL: Unable to produce a script file Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to lucene at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1036) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) java.io.IOException: No space left on device at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1456) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1428) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918) 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:748) Caused: java.io.IOException: remote file operation failed: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.remoting.Channel@2755bcce:lucene at hudson.FilePath.act(FilePath.java:1043) at hudson.FilePath.act(FilePath.java:1025) at hudson.FilePath.createTextTempFile(FilePath.java:1423) Caused: java.io.IOException: Failed to create a temp file on /home/jenkins/jenkins-slave/workspace/Lucene-Solr-repro at hudson.FilePath.createTextTempFile(FilePath.java:1425) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:162) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:94) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1595 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1595/ 3 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Captured an uncaught exception in thread: Thread[id=8845, name=Connection evictor, state=RUNNABLE, group=TGRP-FullSolrCloudDistribCmdsTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=8845, name=Connection evictor, state=RUNNABLE, group=TGRP-FullSolrCloudDistribCmdsTest] at __randomizedtesting.SeedInfo.seed([F4EBCF770C786DA6:7CBFF0ADA284005E]:0) Caused by: java.lang.OutOfMemoryError: Java heap space at __randomizedtesting.SeedInfo.seed([F4EBCF770C786DA6]:0) at org.apache.http.pool.AbstractConnPool.closeExpired(AbstractConnPool.java:633) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.closeExpiredConnections(PoolingHttpClientConnectionManager.java:415) at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:67) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.FullSolrCloudDistribCmdsTest Error Message: ObjectTracker found 4 object(s) that were not released!!! [ZkShardTerms, ZkShardTerms, ZkShardTerms, ZkShardTerms] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.ZkShardTerms at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.ZkShardTerms.(ZkShardTerms.java:93) at org.apache.solr.cloud.ZkCollectionTerms.getShard(ZkCollectionTerms.java:45) at org.apache.solr.cloud.ZkController.getShardTerms(ZkController.java:1555) at org.apache.solr.cloud.ZkController.register(ZkController.java:1115) at org.apache.solr.cloud.ZkController$RegisterCoreAsync.call(ZkController.java:264) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.ZkShardTerms at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.ZkShardTerms.(ZkShardTerms.java:93) at org.apache.solr.cloud.ZkCollectionTerms.getShard(ZkCollectionTerms.java:45) at org.apache.solr.cloud.ZkController.getShardTerms(ZkController.java:1555) at org.apache.solr.cloud.ZkController.register(ZkController.java:1115) at org.apache.solr.cloud.ZkController$RegisterCoreAsync.call(ZkController.java:264) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.ZkShardTerms at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.ZkShardTerms.(ZkShardTerms.java:93) at org.apache.solr.cloud.ZkCollectionTerms.getShard(ZkCollectionTerms.java:45) at org.apache.solr.cloud.ZkController.getShardTerms(ZkController.java:1555) at org.apache.solr.cloud.ZkController.register(ZkController.java:1115) at org.apache.solr.cloud.ZkController$RegisterCoreAsync.call(ZkController.java:264) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.cloud.ZkShardTerms at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.cloud.ZkShardTerms.(ZkShardTerms.java:93) at org.apache.solr.cloud.ZkCollectionTerms.getShard(ZkCollectionTerms.java:45) at org.apache.solr.cloud.ZkController.getShardTerms(ZkController.java:1555) at org.apache.solr.cloud.ZkController.register(ZkController.java:1115) at org.apache.solr.cloud.ZkController$RegisterCoreAsync.call(ZkController.java:264) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559949#comment-16559949
]
Adrien Grand commented on LUCENE-8432:
--
+1 to do it this way too. I don't have a suggestion at the moment but maybe we
can find a more explicit name than {{docsDone}}.
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> OrHighNotMed 87.06 (3.7%) 87.80 (4.1%)
> 0.8% ( -6% - 8%)
> IntNRQ 26.44 (12.8%) 26.68 (11.5%)
> 0.9% ( -20% - 28%)
> HighTerm 107.64 (6.1%) 108.88 (5.6%)
> 1.2% ( -9% - 13%)
>
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 2428 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2428/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild Error Message: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException Stack Trace: java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException at __randomizedtesting.SeedInfo.seed([B5E7366B22A14E3C:6A6A54D41CC81B5E]:0) at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: junit.framework.AssertionFailedError: Unexpected wrapped ex
[jira] [Created] (LUCENE-8433) Add FutureArrays.equals(Object[] a, int aToIndex, Object[] b, int bFromIndex, int bToIndex)
Michael Braun created LUCENE-8433:
-
Summary: Add FutureArrays.equals(Object[] a, int aToIndex,
Object[] b, int bFromIndex, int bToIndex)
Key: LUCENE-8433
URL: https://issues.apache.org/jira/browse/LUCENE-8433
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael Braun
Noticed code like the following in TopFieldCollector:
{code}
if (fields1.length > fields2.length) {
return false;
}
return Arrays.asList(fields1).equals(Arrays.asList(fields2).subList(0,
fields1.length));
{code}
This can be simplified and made more efficient by using Arrays.equals(Object[]
a, int aToIndex, Object[] b, int bFromIndex, int bToIndex) , which is only
present in Java 9+. (Though it is not taking advantage of any intrinsics like
the primitive arrays do, since it uses object equality rather than reference
equality). This can be added as part of FutureArrays.java - this would serve
to simplify code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-12572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559893#comment-16559893
]
Amrit Sarkar edited comment on SOLR-12572 at 7/27/18 3:31 PM:
--
Uploaded recent patch; which fix {{testRandomNumerics}} but we are skipping
optimization when field-values are not available / empty / null.
Introduced new boolean {{valNotNull}} for implementations of {{SortValue}}
which keeps check whether the field getting fetched has actual value or not.
was (Author: sarkaramr...@gmail.com):
Uploaded recent patch; which fix {{testRandomNumerics}} but we are skipping
optimization when fieldvalues are not available / empty / null.
> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch,
> SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query&sort=severity+desc,timestamp+desc&fl=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example
> 'severity, 'timestamp'). When we stream out docs we again make doc-value
> seeks against the {{fl}} fields ('severity','timestamp','msg') .
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values
> while sorting it, we can reduce the doc-value seeks potentially bringing
> *speed improvement*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-12572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559893#comment-16559893
]
Amrit Sarkar commented on SOLR-12572:
-
Uploaded recent patch; which fix {{testRandomNumerics}} but we are skipping
optimization when fieldvalues are not available / empty / null.
> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch,
> SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query&sort=severity+desc,timestamp+desc&fl=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example
> 'severity, 'timestamp'). When we stream out docs we again make doc-value
> seeks against the {{fl}} fields ('severity','timestamp','msg') .
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values
> while sorting it, we can reduce the doc-value seeks potentially bringing
> *speed improvement*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-12572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12572:
Attachment: SOLR-12572.patch
> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch,
> SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query&sort=severity+desc,timestamp+desc&fl=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example
> 'severity, 'timestamp'). When we stream out docs we again make doc-value
> seeks against the {{fl}} fields ('severity','timestamp','msg') .
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values
> while sorting it, we can reduce the doc-value seeks potentially bringing
> *speed improvement*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12598) Do not fetch non-stored fields
Nikolay Khitrin created SOLR-12598: -- Summary: Do not fetch non-stored fields Key: SOLR-12598 URL: https://issues.apache.org/jira/browse/SOLR-12598 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.3 Reporter: Nikolay Khitrin When fl parameter is used RetrieveFieldsOptimizer keeps non-stored fields in storedFields set and therefore DocsStreamer fetches document even if no stored fields requested. The very simple and straightforward patch attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12598) Do not fetch non-stored fields
[ https://issues.apache.org/jira/browse/SOLR-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Khitrin updated SOLR-12598: --- Attachment: SOLR-12598.patch > Do not fetch non-stored fields > -- > > Key: SOLR-12598 > URL: https://issues.apache.org/jira/browse/SOLR-12598 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3 >Reporter: Nikolay Khitrin >Priority: Major > Attachments: SOLR-12598.patch > > > When fl parameter is used RetrieveFieldsOptimizer keeps non-stored fields in > storedFields set and therefore DocsStreamer fetches document even if no > stored fields requested. > The very simple and straightforward patch attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries
[ https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559870#comment-16559870 ] Adrien Grand commented on LUCENE-8422: -- I'm curious whether you considered adding eg. IntervalsSource#matches instead of IntervalIterator#collect, which would be more aligned with how things work on regular queries? > Add Matches iteration to interval queries > - > > Key: LUCENE-8422 > URL: https://issues.apache.org/jira/browse/LUCENE-8422 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8422.patch > > > Follow up to LUCENE-8404, we can now add Matches iteration to interval > queries in the sandbox. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+24) - Build # 22540 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22540/ Java: 64bit/jdk-11-ea+24 -XX:+UseCompressedOops -XX:+UseSerialGC 8 tests failed. FAILED: org.apache.solr.cloud.DeleteShardTest.testDirectoryCleanupAfterDeleteShard Error Message: Could not find collection : deleteshard_test Stack Trace: org.apache.solr.common.SolrException: Could not find collection : deleteshard_test at __randomizedtesting.SeedInfo.seed([46BBC8A79E5D46D6:E6A183FC3A2D0DDA]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:256) at org.apache.solr.cloud.DeleteShardTest.testDirectoryCleanupAfterDeleteShard(DeleteShardTest.java:113) 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:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.cloud.DeleteShardTest.testDirectoryCleanupAfterDeleteShard Error Message: Could not find collection : deleteshard_test Stack Trace: org.
Re: [JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 749 - Failure!
Thanks Adrien!
On Fri, Jul 27, 2018 at 3:22 PM Adrien Grand wrote:
> I just pushed a fix.
>
> Le ven. 27 juil. 2018 à 11:34, Policeman Jenkins Server <
> jenk...@thetaphi.de> a écrit :
>
>> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/749/
>> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
>>
>> All tests passed
>>
>> Build Log:
>> [...truncated 12144 lines...]
>> [javac] Compiling 923 source files to
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build/solr-core/classes/test
>> [javac]
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/core/src/test/org/apache/solr/cloud/MigrateRouteKeyTest.java:96:
>> error: no suitable method found for
>> expectThrows(Class,String,()->{ Coll[...])); })
>> [javac] HttpSolrClient.RemoteSolrException remoteSolrException =
>> expectThrows(HttpSolrClient.RemoteSolrException.class,
>> [javac] ^
>> [javac] method
>> LuceneTestCase.expectThrows(Class,ThrowingRunnable) is not applicable
>> [javac] (cannot infer type-variable(s) T
>> [javac] (actual and formal argument lists differ in length))
>> [javac] method
>> LuceneTestCase.expectThrows(Class,Class,ThrowingRunnable) is
>> not applicable
>> [javac] (cannot infer type-variable(s) TO,TW
>> [javac] (argument mismatch; String cannot be converted to
>> Class))
>> [javac] where T,TO,TW are type-variables:
>> [javac] T extends Throwable declared in method
>> expectThrows(Class,ThrowingRunnable)
>> [javac] TO extends Throwable declared in method
>> expectThrows(Class,Class,ThrowingRunnable)
>> [javac] TW extends Throwable declared in method
>> expectThrows(Class,Class,ThrowingRunnable)
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -Xlint:deprecation for details.
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] 1 error
>>
>> BUILD FAILED
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:633: The
>> following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:577: The
>> following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:59: The
>> following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build.xml:267:
>> The following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/common-build.xml:556:
>> The following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:896:
>> The following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:908:
>> The following error occurred while executing this line:
>> /export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2050:
>> Compile failed; see the compiler error output for details.
>>
>> Total time: 16 minutes 48 seconds
>> Build step 'Invoke Ant' marked build as failure
>> Archiving artifacts
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>> [WARNINGS] Skipping publisher since build result is FAILURE
>> Recording test results
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>> Setting
>> ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
--
Regards,
Shalin Shekhar Mangar.
Re: query other solr collection from within a solr plugin
Sure, it's up to you. But if for matter of fact, it EmbeddedSolrServer request has "collection" param, it pulls shards from zk and executed distributed request. see http://people.apache.org/~mkhl/searchable-solr-guide-7-3/transforming-result-documents.html#cores-and-collections-in-solrcloud https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java#L323 On Fri, Jul 27, 2018 at 11:48 AM Nicolas Franck wrote: > From what I've seen now, it seems that you can only directly connect to a > specific core on your own node, > right? Should have expected that: it is local ;-) > > Then I'll stick to the old solution that worked after all. > > Thanks for all the advice > > On 26 Jul 2018, at 14:28, Mikhail Khludnev wrote: > > [subquery] calls remote cloud collections if collection parameter (which > is somewhat not well known, documented) is supplied > > https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/transform/SubQueryAugmenterFactory.java#L334 > > > On Thu, Jul 26, 2018 at 3:05 PM Nicolas Franck > wrote: > >> I'm writing a solr plugin in java that has to query another solr >> collection to gather >> information. What is the best way to do this? >> >> For now I'm just using a SolrClient ( CloudSolrClient ), but has several >> disadvantages: >> >> * you have to extract from core metadata where your server resides, and >> setup your SolrClient accordingly. >> * you are just knocking at the same door >> * search has to go over http for the same core. >> >> Is there a better way? Are there any examples? >> >> Thanks in advance >> >> Nicolas Franck >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > Sincerely yours > Mikhail Khludnev > > > -- Sincerely yours Mikhail Khludnev
[JENKINS] Lucene-Solr-Tests-master - Build # 2624 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2624/ 2 tests failed. FAILED: org.apache.solr.cloud.ShardRoutingTest.test Error Message: expected:<3> but was:<4> Stack Trace: java.lang.AssertionError: expected:<3> but was:<4> at __randomizedtesting.SeedInfo.seed([C46B92BFF8097181:4C3FAD6556F51C79]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ShardRoutingTest.doTestNumRequests(ShardRoutingTest.java:256) at org.apache.solr.cloud.ShardRoutingTest.test(ShardRoutingTest.java:110) 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:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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)
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10.0.1) - Build # 718 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/718/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180727153422284, index.20180727153435325, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180727153422284, index.20180727153435325, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([41F1E1EB9DAD9C21:9A5AE12D9885F592]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:969) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:940) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:916) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$St
[jira] [Commented] (LUCENE-8432) Stop calling comparator even if early termination is not possible
[
https://issues.apache.org/jira/browse/LUCENE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559721#comment-16559721
]
Jim Ferenczi commented on LUCENE-8432:
--
Thanks [~khitrin], the change makes sense to me. The other way to achieve this
optimization is to use a MultiCollector that wraps a TotalHitCountCollector and
a TopFieldCollector but I prefer the solution that you propose. It's much
simpler if this can be done automatically by the top field collector. Any
objections [~jpountz] ?
> Stop calling comparator even if early termination is not possible
> -
>
> Key: LUCENE-8432
> URL: https://issues.apache.org/jira/browse/LUCENE-8432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 7.3
>Reporter: Nikolay Khitrin
>Priority: Minor
> Attachments: LUCENE-8432.patch
>
>
> TopFieldCollector continues calling comparator.compareBottom even if result
> is known in advance due to document order when trackMaxScore or
> trackTotalHits is set.
> Comparator call is not very cheap because it can involve DV read from disk
> and all calls can be avoided after first non competitive segment document is
> reached.
> There is a patch and luceneutil report on wikimedium10m sorted by DayOfYear:
> {noformat}
> TaskQPS baseline StdDev QPS patch StdDev
> Pct diff
> HighTermMonthSort 226.04 (6.3%) 215.33 (4.3%)
> -4.7% ( -14% - 6%)
> LowTerm 933.27 (5.5%) 924.62 (4.2%)
> -0.9% ( -10% - 9%)
> OrNotHighLow 945.68 (5.7%) 939.12 (4.5%)
> -0.7% ( -10% - 10%)
> MedSpanNear 28.76 (1.4%) 28.61 (1.5%)
> -0.5% ( -3% - 2%)
> BrowseDayOfYearSSDVFacets 16.36 (5.0%) 16.29 (4.5%)
> -0.4% ( -9% - 9%)
> AndHighMed 112.30 (2.9%) 111.96 (1.6%)
> -0.3% ( -4% - 4%)
> LowSpanNear 12.42 (1.5%) 12.38 (1.6%)
> -0.3% ( -3% - 2%)
> HighSloppyPhrase 18.66 (3.9%) 18.62 (4.0%)
> -0.2% ( -7% - 7%)
> MedPhrase 219.40 (2.7%) 219.06 (2.7%)
> -0.2% ( -5% - 5%)
> OrNotHighMed 222.88 (3.2%) 222.63 (3.4%)
> -0.1% ( -6% - 6%)
> AndHighLow 521.59 (3.5%) 521.02 (4.5%)
> -0.1% ( -7% - 8%)
> MedSloppyPhrase 16.71 (4.7%) 16.70 (4.7%)
> -0.0% ( -8% - 9%)
> LowPhrase 15.58 (2.5%) 15.59 (2.9%)
> 0.0% ( -5% - 5%)
> Respell 92.05 (2.4%) 92.19 (3.0%)
> 0.2% ( -5% - 5%)
> HighSpanNear 17.03 (2.2%) 17.06 (2.1%)
> 0.2% ( -4% - 4%)
> HighPhrase 37.85 (5.8%) 37.92 (5.9%)
> 0.2% ( -10% - 12%)
> OrHighNotLow 118.25 (2.9%) 118.47 (3.5%)
> 0.2% ( -6% - 6%)
> BrowseMonthTaxoFacets 2.94 (0.4%) 2.94 (0.8%)
> 0.2% ( 0% - 1%)
> BrowseDateTaxoFacets 2.75 (0.3%) 2.75 (1.6%)
> 0.3% ( -1% - 2%)
> LowSloppyPhrase 105.28 (2.3%) 105.60 (2.5%)
> 0.3% ( -4% - 5%)
> Prefix3 122.07 (6.8%) 122.55 (6.5%)
> 0.4% ( -12% - 14%)
> OrNotHighHigh 55.07 (3.8%) 55.29 (4.5%)
> 0.4% ( -7% - 8%)
> BrowseMonthSSDVFacets 20.88 (7.2%) 20.99 (7.5%)
> 0.5% ( -13% - 16%)
> OrHighNotHigh 58.40 (4.2%) 58.72 (4.8%)
> 0.6% ( -8% - 9%)
> Wildcard 79.87 (3.7%) 80.31 (4.0%)
> 0.6% ( -6% - 8%)
> OrHighMed 13.25 (4.3%) 13.34 (4.9%)
> 0.6% ( -8% - 10%)
> BrowseDayOfYearTaxoFacets 2.73 (0.6%) 2.75 (1.6%)
> 0.7% ( -1% - 2%)
> OrHighHigh 22.03 (4.1%) 22.19 (4.9%)
> 0.7% ( -8% - 10%)
> AndHighHigh 23.46 (2.1%) 23.63 (1.9%)
> 0.7% ( -3% - 4%)
> PKLookup 145.59 (4.2%) 146.66 (4.3%)
> 0.7% ( -7% - 9%)
> MedTerm 171.13 (5.0%) 172.43 (5.1%)
> 0.8% ( -8% - 11%)
> OrHighLow 119.22 (2.8%) 120.23 (3.1%)
> 0.8% ( -4% - 6%)
> OrHighNotMed 87.06 (3.7%) 87.80 (4.1%)
> 0.8% ( -6% - 8%)
>
[GitHub] lucene-solr issue #425: WIP SOLR-12555: refactor tests to use expectThrows
Github user gerlowskija commented on the issue: https://github.com/apache/lucene-solr/pull/425 Thanks for all the work Bar. I'm going to run the tests throughout the day and I hope to get this merged this evening or this weekend. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8419) Return token unchanged for pathological Stempel tokens
[ https://issues.apache.org/jira/browse/LUCENE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559683#comment-16559683 ] Adrien Grand commented on LUCENE-8419: -- [~ab] Do you have any ideas how to improve this? > Return token unchanged for pathological Stempel tokens > -- > > Key: LUCENE-8419 > URL: https://issues.apache.org/jira/browse/LUCENE-8419 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Trey Jones >Priority: Major > Labels: stemmer, stemming > Attachments: dotc.txt, dotdotc.txt, twoletter.txt > > > In the aggregate, Stempel does a good job, but certain tokens get stemmed > pathologically, conflating completely unrelated words in the search index. > Depending on the scoring function, documents returned may have no form of the > word that was in the query, only unrelated forms (see ć examples below). > It's probably not possible to fix the stemmer, and it's probably not possible > to catch _every_ error, but catching and ignoring certain large classes of > errors would greatly improve precision, and doing it in the stemmer would > prevent losses to recall that happen from cleaning up these errors outside > the stemmer. > An obvious example is that numbers ending in 1 have the last two digits > replaced with ć. So 12341 is stemmed as 123ć. Numbers ending in 31 have the > last 4 numbers removed and replaced with ć, so 12331 is stemmed as 1ć. Mixed > letters and numbers are treated the same: abc123451 is stemmed as abc1234ć, > abc1231 is stemmed as abcć. > *Proposed solution:* any token that ends in a number should not be stemmed, > it should just be returned unchanged. > One letter stems from the set [a-zńć] are generally useless and often absurd. > ć is the worst offender by far (it's the ending of the infinitive form of > verbs). All of these tokens (found on Polish Wikipedia/Wiktionary) get > stemmed to ć: > * acque Adrien aguas Águas Alainem Alandh Amores Ansoe Arau asinaio aŭdas > audyt Awiwie Ayres Baby badż Baina Bains Balue Baon baque Barbola Bazy Beau > beim Beroe Betz Blaue blenda bleue Blizzard boor Boruca Boym Brodła Brogi > Bronksie Brydż Budgie Budiafa bujny Buon Buot Button Caan Cains Canoe Canona > caon Celu Charl Chloe ciag Cioma Cmdr Conseil Conso Cotton Cramp Creel Cuyk > cyan czcią Czermny czto D.III Daws Daxue dazzle decy Defoe Dereń Detroit > digue Dior Ditton Dojlido dosei douk DRaaS drag drau Dudacy dudas Dutton Duty > Dziób eayd Edwy Edyp eiro Eltz Emain erar ESaaS faan Fetz figurar Fitz foam > Frau Fugue GAAB gaan Gabirol Gaon gasue Gaup Geol GeoMIP Getz gigue Ginny > Gioią Girl Goam Gołymin Gosei Götz grasso Grodnie Gula Guroo gyan HAAB Haan > Heim Héroe Hitz Hoam Hohenho Hosei Huon Hutton Huub hyaina Iberii inkuby > Inoue Issue ITaaS Iudas Izmaile Jaan Jaws jedyn Jews jira Josepho Jost Josue > Judas Kaan Kaleido Karoo Katz Kazue Kehoe khayag kiwa Kiwu Klaas kmdr Kokei > Konoe kozer kpią Kringle ksiezyce Któż Kutz L231 L331 Laan Lalli Laon Laws > łebka Leroo Liban Ligue Liro Lisoli Logue Loja Londyn Lubomyr Luque Lutz > Lytton łzawy Maan mains Mainy malpaco Mammal mandag MBaaS meeki Merl Metz > MIDAS middag Miras mmol modą moins Monty Moryń motz mróż Mutz Müzesi MVaaS > Naam nabrzeża Nadab Nadala Nalewki Nd:YAG neol News Nieszawa Nimue Nyam ÖAAB > oblał oddala okala Olień opar oppi Orioł Osioł osoagi Osyki Otóż Output > Oxalido pasmową Patton Pearl Peau peoplk Petz poar Pobrzeża poecie Pogue Pono > posagi posł Praha Pringle probie progi Prońko Prosper prwdę Psioł Pułka Putz > QDTOE Quien Qwest radża raga Rains reht Reich Retz Revue Right RITZ Roam > Rogue Roque rosii RU31 Rutki Ryan SAAB saasso salue Sampaio Satz Sears > Sekisho semo Setton Sgan Siloe Sitz Skopje Slot Šmarje Smrkci Soar sopo > sozinho springa Steel Stip Straz Strip Suez sukuby Sumach Surgucie Sutton > svasso Szosą szto Tadas Taira tęczy Teodorą teol Tisii Tisza Toluca Tomoe > Toque TPMŻ Traiana Trask Traue Tulyag Tuque Turinga Undas Uniw usque Vague > Value Venue Vidas Vogue Voor W331 Waringa weht Weich Weija Wheel widmem WKAG > worku Wotton Wryk Wschowie wsiach wsiami Wybrzeża wydala Wyraz XLIII XVIII > XXIII Yaski yeol YONO Yorki zakręcie Zijab zipo. > Four-character tokens ending in 31 (like 2,31 9,31 1031 1131 7431 8331 a331) > also all get stemmed to ć. > Below are examples of other tokens (from Polish Wikipedia/Wiktionary) that > get stemmed to one-letter tokens in [a-zńć]. Note that i, o, u, w, and z are > stop words, and so don't show up in the list. > * a: a, addo, adygea, jhwh, also > * b: b, bdrm, barr, bebek, berr, bounty, bures, burr, berm, birm > * c: alzira, c, carr, county, haight, hermas, kidoń, paich, pieter, połóż, > radoń, soest, tatort, voight,
[jira] [Commented] (SOLR-12494) Migration documentation
[ https://issues.apache.org/jira/browse/SOLR-12494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559643#comment-16559643 ] Ana commented on SOLR-12494: Hi Erick, I followed your suggestion in migrating the data and swapping the drive letter and now i ran in the following scenario: SOLR 1 issues -Server 1 Cannot run zookeeper services on all intances Error in the zookeeper logs: Unable to load database on disk java.io.IOException: The accepted epoch, 19 is less than the current epoch, 63d Research over the internet https://issues.apache.org/jira/browse/ZOOKEEPER-2307 Notes: I can navigate to http://xx.xxx.xxx.xxx:8986/solr/ - however i cannot see the collections and instances http://xx.xxx.xxx.xxx:8983/solr/en_cache/admin/ping -ok --instance 1 http://xx.xxx.xxx.xxx:8984/solr/en_cache/admin/ping - 500 internal error --instance 2 http://xx.xxx.xxx.xxx:8985/solr/en_cache/admin/ping - 500 internal error --instance 3 http://xx.xxx.xxx.xxx:8986/solr/en_cache/admin/ping - 500 internal error --instance 4 SOLR 2 -Server 2 http://xx.xxx.xxx.xxx:8983/solr/en_cache/admin/ping -ok --instance 1 http://xx.xxx.xxx.xxx:8984/solr/en_cache/admin/ping - 500 internal error --instance 2 http://xx.xxx.xxx.xxx:8985/solr/en_cache/admin/ping - 500 internal error --instance 3 http://xx.xxx.xxx.xxx:8986/solr/en_cache/admin/ping - 500 internal error --instance 4 http://localhost:8983/solr/#/en_cache_shard1_replica2- icann see the collections All services are started and are in running state However the error found is: Zookeeper error: Cannot open channel to X at election address Architecture: We have 2 SOLR servers Load balanced SOLR1 and SOLR 2 whereby we have installed 4 instances on both SOLRs. Many thanks in advance!! Ana On Thu, Jul 5, 2018 at 8:29 PM, Alexandre Rafalovitch (JIRA) < -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. > Migration documentation > > > Key: SOLR-12494 > URL: https://issues.apache.org/jira/browse/SOLR-12494 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 6.4.2 > Environment: Stage >Reporter: Ana >Priority: Trivial > > I have the following scenario, I'm having a shared cluster solr installation > environment (app server 1-app server 2 load balanced) which has 4 solr > instances. > > After reviewing the space audit we have noticed that the partition where the > installation resides is too big versus what is used in term of space. > > Therefore we have installed a new drive which is smaller and now we want to > migrate from the old dive (E:) to the new drive (F). > > Can you please provide an official answer whether this is a supported > scenario? > > If yes, will you please share the steps with us? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10.0.1) - Build # 7450 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7450/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180727144347575, index.20180727144400039, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180727144347575, index.20180727144400039, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([6C60825063E66619:B7CB829666CE0FAA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:969) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:940) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:916) 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:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) 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:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) 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 com.carrotsearch.randomizedtesting.ThreadLeakControl$
Re: SynonymGraphFilter followed by StopFilter
No Solr patches necessary: synonymquery fixed that IDF issue 3 years ago. There is just extremely outdated advice on this thread. On Fri, Jul 27, 2018 at 7:08 AM, Alessandro Benedetti wrote: > Hi all, > I just want to add that > "With synonyms at query time, you’ll see different idf for terms in the > synonym set, with the rare variant scoring higher. That is probably the > opposite of what is expected." > should be solved by : https://issues.apache.org/jira/browse/SOLR-11662 > > At least that feature brings flexibility in. > > Cheers > > -- > Alessandro Benedetti > Search Consultant, R&D Software Engineer, Director > www.sease.io > > On Fri, Jul 27, 2018 at 3:25 AM, Michael Sokolov > wrote: > >> > In general I’d avoid index-time synonyms in lucene because synonyms >> can create graphs (eg if a single term gets expanded to several terms), and >> we can’t index graphs correctly. >> >> I wonder what it would take to address this. I guess the blast radius of >> adding a token "width" could be pretty large. Is there an issue or any past >> discussion about that? >> >> On Thu, Jul 26, 2018 at 11:42 AM Andrea Gazzarini >> wrote: >> >>> Hi Walter, >>> many thanks for the response and without any constraint at all, I would >>> agree with you. From your message I clearly understand your experience is >>> greater than mine. My 2 cents inline below: >>> >>> > Move the synonym filter to the index analyzer chain. That provides >>> better performance and avoids some surprising relevance behavior. With >>> synonyms at query time, you’ll see different idf for terms in the synonym >>> set, with the rare variant scoring higher. That is probably the opposite of >>> what is expected. >>> >>> Unfortunately moving the synonym filter to the index analyzer is not an >>> option: the project where I'm working on has a huge index and the synonyms >>> list is something that (at least in this stage) frequently changes; >>> re-index everything from scratch each time a change occurs is a big >>> problem. On the other side, the IDF issue you mention doesn't produce so >>> many unwanted effect, at least until now. But I got the point, thanks for >>> the hint. >>> >>> > Also, phrase synonyms just don’t work at query time because the terms >>> are parsed into individual tokens by the query parser, not the tokenizer. >>> Here I dont' get you: using the SynonymGraph Filter + SplitOnWhiteSpace >>> = false + AutoGeneratePhraseQueries I get the synonym phrasing correctly >>> working (see the first example in my email). >>> >>> > Don’t use stop words. Just remove that line. Removing stop words is a >>> performance and space hack that was useful in the 1960’s, but causes >>> problems now. I’ve never used stop word removal and I started in search >>> with Infoseek in 1996. Stop word removal is like a binary idf, ignoring >>> common words. Since we have idf, we can give a lower score to common words >>> and keep them in the index. >>> >>> And this is, as I see, something which animated long discussions around >>> using / avoiding stopwords. I will check your suggestion, what it means to >>> apply that approach to my project, but in meantime I think, also looking at >>> the JIRA Alan pointed in his answer, the issue is there, and it's real; I >>> mean, it is something that it doesn't work as expected (my use case, as far >>> as I understand, is just an example because the thing is broader and it is >>> related to the FilteredTokenFilter) >>> >>> Thanks again, >>> Andrea >>> >>> On 26/07/18 16:59, Walter Underwood wrote: >>> >>> Move the synonym filter to the index analyzer chain. That provides >>> better performance and avoids some surprising relevance behavior. With >>> synonyms at query time, you’ll see different idf for terms in the synonym >>> set, with the rare variant scoring higher. That is probably the opposite of >>> what is expected. >>> >>> Also, phrase synonyms just don’t work at query time because the terms >>> are parsed into individual tokens by the query parser, not the tokenizer. >>> >>> Don’t use stop words. Just remove that line. Removing stop words is a >>> performance and space hack that was useful in the 1960’s, but causes >>> problems now. I’ve never used stop word removal and I started in search >>> with Infoseek in 1996. Stop word removal is like a binary idf, ignoring >>> common words. Since we have idf, we can give a lower score to common words >>> and keep them in the index. >>> >>> Do those two things and it should work as you expect. >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org >>> http://observer.wunderwood.org/ (my blog) >>> >>> On Jul 26, 2018, at 3:23 AM, Andrea Gazzarini >>> wrote: >>> >>> Hi Alan, thanks for the response and thank you very much for the pointers >>> >>> On 26/07/18 12:16, Alan Woodward wrote: >>> >>> Hi Andrea, >>> >>> This is a long-standing issue: see https://issues.apache.org/ >>> jira/browse/LUCENE-4065 and https://issues.apache.org/jira/b >>> row
[jira] [Resolved] (LUCENE-8429) DaciukMihovAutomatonBuilder needs protection against stack overflows
[ https://issues.apache.org/jira/browse/LUCENE-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-8429. -- Resolution: Fixed Fix Version/s: 7.5 master (8.0) > DaciukMihovAutomatonBuilder needs protection against stack overflows > > > Key: LUCENE-8429 > URL: https://issues.apache.org/jira/browse/LUCENE-8429 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Fix For: master (8.0), 7.5 > > Attachments: LUCENE-8429.patch > > > The maximum level of recursion of this class is the maximum term length, > which is not low enough to ensure it never fails with a stack overflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8410) Soft delete optimization never kicks in
[ https://issues.apache.org/jira/browse/LUCENE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-8410. -- Resolution: Fixed Fix Version/s: 7.5 master (8.0) Commit notifications went to LUCENE-8420 because of a typo in my commit message. > Soft delete optimization never kicks in > --- > > Key: LUCENE-8410 > URL: https://issues.apache.org/jira/browse/LUCENE-8410 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Fix For: master (8.0), 7.5 > > Attachments: LUCENE-8410.patch > > > SoftDeletesRetentionMergePolicy and SoftDeletesDirectoryReaderWrapper have an > optimized code path in case live docs implement FixedBitSet, which is never > true anymore since LUCENE-8309. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
