[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413399#comment-16413399
]
Varun Thacker commented on SOLR-7887:
-
5. In solr/contrib/prometheus-exporter/ivy.xml , why is the "log4j-slf4j-impl"
dependency "test" and not "compile" ?
Excerpt where this was changed
{code:java}
-
+ {code}
6. The commit to JettySolrRunner.java seems like a cruft from a older patch?
7. In solr/server/resources/log4j2.xml , we have added this
{code:java}
fileName="${sys:solr.solr.home}/../logs/solr.log"{code}
why is it "solr.solr.home" ? Shouldn't it be ${solr.log} ?
>From the older log4j.properties
{code:java}
log4j.appender.file.File=${solr.log}/solr.log{code}
8. In solr/server/scripts/cloud-scripts/log4j2.xml , we have this line
{code:java}
{code}
the "log4j.logger" should be excluded right?
9. Similarly in solr/solrj/src/test-files/log4j2.xml and
solr/solrj/src/test-files/log4j.properties we need to fix this?
{code:java}
{code}
> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
>
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
> Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch,
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final
> logging destination, so the admin UI has a log watcher that actually uses
> log4j and java.util.logging classes. That will need to be extended to add
> log4j2. I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j. Figuring out exactly which
> jars need to be in the lib/ext directory will take some research.
--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413395#comment-16413395
]
Shalin Shekhar Mangar commented on SOLR-7887:
-
I see {{}} in
{{solr/server/resources/log4j2.xml}} instead of the new defaults in SOLR-11957.
Also, what is the equivalent of the old {{MaxBackupIndex}} parameter and where
is it configured in the new scheme of things?
> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
>
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
> Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch,
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final
> logging destination, so the admin UI has a log watcher that actually uses
> log4j and java.util.logging classes. That will need to be extended to add
> log4j2. I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j. Figuring out exactly which
> jars need to be in the lib/ext directory will take some research.
--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413382#comment-16413382 ] Erick Erickson commented on SOLR-7887: -- For <1>, Hoss introduced that for the documentation build process, so I left it. For the rest, can you open a new JIRA or add a patch to fix this up since it's fresh in your mind? > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-7.x-Linux (32bit/jdk1.8.0_162) - Build # 14 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/14/ Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([6CC5D2B5633C4CE:2AFE2AA6DAF7B24A]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:914) at org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads(AtomicUpdateProcessorFactoryTest.java:264) 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) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=int_i:14=xml at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:907) ... 40 more Build Log: [...truncated 1788
[jira] [Updated] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-7887: Affects Version/s: (was: 5.2.1) > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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] [Reopened] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker reopened SOLR-7887: - > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413360#comment-16413360
]
Varun Thacker commented on SOLR-7887:
-
I validated two things from the Solr Admin UI
* ERRORs and WARNs getting logged correctly
* Changing log levels dynamically works correctly. Changed it a few times
thought the UI and toggled it around and the solr logs reflects it
A few comments from the patch.
1. In lucene/ivy-versions.properties we have something like this. Any reason we
can't set org.log4j.major.version = 2.11.0 and don't use the minor version
variable?
{code:java}
org.log4j.major.version = 2.11
org.log4j.minor.version = 0
org.apache.logging.log4j.version =
${org.log4j.major.version}.${org.log4j.minor.version}{code}
2. After applying the patch , the CHANGES entry has a formatting issue . The
upgrade section shouldn't contain the author names .
3. The CHANGES entry needs to reflect Log4J 2.11 instead of 2.10
4. If you grep for "log4j.properties" the new dev-tools/eclipse/run*.sh files
references them that needs to be updated. Also
solr/contrib/prometheus-exporter/bin/solr-exporter* references it.
4. Same as 4, where those files need to use -Dlog4j.configurationFile instead
of -Dlog4j.configuration . Additionally solr/bin/solr.cmd has one mention of
-Dlog4j.configuration which would need to be updated ass well.
I'm still looking at the remaining of the patch and will post my second update
in a bit
> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
>
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
> Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch,
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch,
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final
> logging destination, so the admin UI has a log watcher that actually uses
> log4j and java.util.logging classes. That will need to be extended to add
> log4j2. I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j. Figuring out exactly which
> jars need to be in the lib/ext directory will take some research.
--
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 # 20 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/20/ 5 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Captured an uncaught exception in thread: Thread[id=6814, name=coreZkRegister-1736-thread-1, state=RUNNABLE, group=TGRP-DeleteReplicaTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=6814, name=coreZkRegister-1736-thread-1, state=RUNNABLE, group=TGRP-DeleteReplicaTest] at __randomizedtesting.SeedInfo.seed([8D83493A1500EB11:E79528EA7DF2A1DB]:0) Caused by: java.lang.AssertionError: Failed to delete replica at __randomizedtesting.SeedInfo.seed([8D83493A1500EB11]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.DeleteReplicaTest.lambda$raceConditionOnDeleteAndRegisterReplica$4(DeleteReplicaTest.java:228) at org.apache.solr.core.ZkContainer.lambda$registerInZk$0(ZkContainer.java:185) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) 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) FAILED: org.apache.solr.cloud.autoscaling.SystemLogListenerTest.test Error Message: Trigger was not fired Stack Trace: java.lang.AssertionError: Trigger was not fired at __randomizedtesting.SeedInfo.seed([8D83493A1500EB11:5D776E0BBFC86E9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.SystemLogListenerTest.test(SystemLogListenerTest.java:151) 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
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+5) - Build # 7241 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7241/ Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger Error Message: expected:<3> but was:<2> Stack Trace: java.lang.AssertionError: expected:<3> but was:<2> at __randomizedtesting.SeedInfo.seed([265092E8E1DC081E:459BA46A78137B33]: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.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:112) at org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:65) 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:841) Build Log:
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk1.8.0_162) - Build # 14 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/14/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC
5 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections
Error Message:
The operations computed by ComputePlanAction should not be
nullSolrClientNodeStateProvider.DEBUG{AFTER_ACTION=[compute_plan, null],
BEFORE_ACTION=[compute_plan, null]}
Stack Trace:
java.lang.AssertionError: The operations computed by ComputePlanAction should
not be nullSolrClientNodeStateProvider.DEBUG{AFTER_ACTION=[compute_plan, null],
BEFORE_ACTION=[compute_plan, null]}
at
__randomizedtesting.SeedInfo.seed([C622B47E37F37E87:FC8C51A70997A7E9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections(ComputePlanActionTest.java:470)
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
[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413298#comment-16413298 ] ASF subversion and git services commented on SOLR-7887: --- Commit dea0fd3267689bbff045cde2762c9726096b3512 in lucene-solr's branch refs/heads/branch_7x from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dea0fd3 ] SOLR-7887: Upgrade Solr to use log4j2 -- log4j 1 now officially end of life (cherry picked from commit 624d128) > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413279#comment-16413279 ] ASF subversion and git services commented on SOLR-7887: --- Commit 624d128b5e745d88adb54bc8505e96cdf6156209 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=624d128 ] SOLR-7887: Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413195#comment-16413195
]
Mikhail Khludnev commented on SOLR-9510:
[~ctargett], would you mind to have a look at [^SOLR-9510-doc.patch]?
> child level facet exclusions
>
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-9510-doc.patch, SOLR-9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up
> to parents, there is a demand for filter exclusions.
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this
> functionality rather than support a separate component.
> * During a discussion in SOLR-8998 a solution for block join with child
> level exclusion has been found.
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly,
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{{!parent}} query parser
> referring to _multiple_ filters queries via parameter name: {{{!parent
> filters=$child.fq ..}..=color:Red=size:XL}}
> these _filters_ are intersected with a child query supplied as a subordinate
> clause.
> * introducing \{{{!filters param=$child.fq excludeTags=color
> v=$subq}=text:word= \{!tag=color}color:Red=size:XL}}
> it intersects a subordinate clause (here it's {{subq}} param, and the trick
> is to refer to the same query from {{{!parent}}}), with multiple filters
> supplied via parameter name {{param=$child.fq}}, it also supports
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into
> {{domain:{..}}} instruction of json facet. From the implementation
> perspective, it's desired to optimize with bitset processing, however I
> suppose it's might be deferred until some initial level of maturity.
> h2. Example
> {code:java}
> q={!parent which=type_s:book filters=$child.fq
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
> 3)=json=on={
> comments_for_author:{
> type:query,
> q:"{!filters param=$child.fq excludeTags=author v=$childquery}",
> "//note":"author filter is excluded",
> domain:{
> blockChildren:"type_s:book",
> "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
> type:terms,
> field:author_s,
> facet: {
> in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
> type:query,
> q:"{!filters param=$child.fq excludeTags=stars v=$childquery}",
> "//note":"stars_i filter is excluded",
> domain:{
> blockChildren:"type_s:book"
>}, facet:{
>stars:{
> type:terms,
> field:stars_i,
> facet: {
> in_books: "unique(_root_)"
> }
> }
> }
> }
> }
> {code}
> Votes? Opinions?
--
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-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9510:
---
Attachment: SOLR-9510-doc.patch
> child level facet exclusions
>
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-9510-doc.patch, SOLR-9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up
> to parents, there is a demand for filter exclusions.
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this
> functionality rather than support a separate component.
> * During a discussion in SOLR-8998 a solution for block join with child
> level exclusion has been found.
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly,
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{{!parent}} query parser
> referring to _multiple_ filters queries via parameter name: {{{!parent
> filters=$child.fq ..}..=color:Red=size:XL}}
> these _filters_ are intersected with a child query supplied as a subordinate
> clause.
> * introducing \{{{!filters param=$child.fq excludeTags=color
> v=$subq}=text:word= \{!tag=color}color:Red=size:XL}}
> it intersects a subordinate clause (here it's {{subq}} param, and the trick
> is to refer to the same query from {{{!parent}}}), with multiple filters
> supplied via parameter name {{param=$child.fq}}, it also supports
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into
> {{domain:{..}}} instruction of json facet. From the implementation
> perspective, it's desired to optimize with bitset processing, however I
> suppose it's might be deferred until some initial level of maturity.
> h2. Example
> {code:java}
> q={!parent which=type_s:book filters=$child.fq
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
> 3)=json=on={
> comments_for_author:{
> type:query,
> q:"{!filters param=$child.fq excludeTags=author v=$childquery}",
> "//note":"author filter is excluded",
> domain:{
> blockChildren:"type_s:book",
> "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
> type:terms,
> field:author_s,
> facet: {
> in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
> type:query,
> q:"{!filters param=$child.fq excludeTags=stars v=$childquery}",
> "//note":"stars_i filter is excluded",
> domain:{
> blockChildren:"type_s:book"
>}, facet:{
>stars:{
> type:terms,
> field:stars_i,
> facet: {
> in_books: "unique(_root_)"
> }
> }
> }
> }
> }
> {code}
> Votes? Opinions?
--
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-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370248#comment-16370248
]
Mikhail Khludnev edited comment on SOLR-9510 at 3/25/18 9:19 PM:
-
hey, yo.. almost without changes in existing code
{code}
"q", "{!parent tag=top filters=$child.fq which=type_s:book v=$childquery}"
, "childquery", "comment_t:*"
, "child.fq", "{!tag=author}author_s:dan"
, "child.fq", "{!tag=stars}stars_i:4"
, "fq", "type_s:book"
, "fl", "id", "fl" , "title_t"
, "json.facet", "{" +
" comments_for_author: {" +
"domain: { excludeTags:\"top\"," + // 1. kick away top bjq,
however, applying parent level fqs
"blockChildren : \"type_s:book\", " + // 2.getting all
children from enlarged parents
" filter:[\"{!filters param=$child.fq " + // 3. filter
children with exclusion
" excludeTags=author v=$childquery}\"]"
+ "}," +
"type:terms," +
"field:author_s," +
"facet: {" +
" in_books: \"unique(_root_)\" }"+//}}," +
" }" +
{code}
patch is coming
was (Author: mkhludnev):
hey, yo.. almost without changes in existing code
{code}
"q", "{!parent tag=top filters=$child.fq which=type_s:book v=$childquery}"
, "childquery", "comment_t:*"
, "child.fq", "{!tag=author}author_s:dan"
, "child.fq", "{!tag=stars}stars_i:4"
, "fq", "type_s:book"
, "fl", "id", "fl" , "title_t"
, "json.facet", "{" +
" comments_for_author: {" +
"domain: { excludeTags:\"top\"," + // 1. kick away top bjq,
however, applying parent level fqs
"blockChildren : \"type_s:book\", " + // 2.getting all
children from enlarged parents
" filter:[\"{!filters params=$child.fq " + // 3. filter
children with exclusion
" excludeTags=author v=$childquery}\"]"
+ "}," +
"type:terms," +
"field:author_s," +
"facet: {" +
" in_books: \"unique(_root_)\" }"+//}}," +
" }" +
{code}
patch is coming
> child level facet exclusions
>
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up
> to parents, there is a demand for filter exclusions.
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this
> functionality rather than support a separate component.
> * During a discussion in SOLR-8998 a solution for block join with child
> level exclusion has been found.
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly,
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{{!parent}} query parser
> referring to _multiple_ filters queries via parameter name: {{{!parent
> filters=$child.fq ..}..=color:Red=size:XL}}
> these _filters_ are intersected with a child query supplied as a subordinate
> clause.
> * introducing \{{{!filters param=$child.fq excludeTags=color
> v=$subq}=text:word= \{!tag=color}color:Red=size:XL}}
> it intersects a subordinate clause (here it's {{subq}} param, and the trick
> is to refer to the same query from {{{!parent}}}), with multiple filters
> supplied via parameter name {{param=$child.fq}}, it also supports
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into
> {{domain:{..}}} instruction of json facet. From the implementation
> perspective, it's desired to optimize with bitset processing, however I
> suppose it's might be deferred until some initial level of maturity.
> h2. Example
> {code:java}
> q={!parent which=type_s:book filters=$child.fq
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
> 3)=json=on={
> comments_for_author:{
> type:query,
> q:"{!filters param=$child.fq excludeTags=author v=$childquery}",
[jira] [Comment Edited] (SOLR-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369586#comment-16369586
]
Mikhail Khludnev edited comment on SOLR-9510 at 3/25/18 9:19 PM:
-
slightly refreshed [^SOLR_9510.patch].
* no changes in Lucene codebase
* it turns -a little bit- scary, however {{query}} facet is redundant. Anyway,
I can't see how to make it shorter:
{code:java}
q={!parent filters=$child.fq which=type_s:book v=$childquery}&
childquery=comment_t:*&
child.fq={!tag=author}author_s:dan&
child.fq={!tag=stars}stars_i:4&
json.facet={
comments_for_author:{
domain:{
excludeTags:author, // 1. rejoin child filters
and query, expand parents docset, apply parent filters (I suppose)
blockChildren:"type_s:book",// 2. join to expanded children
filter:"{!filters param=$child.fq excludeTags=author v=$childquery}"
// 3. filter them again
},
type:terms,
field:author_s,
facet:{
in_books:"unique(_root_)"
}
},
comments_for_stars:{
domain:{
excludeTags:stars,
blockChildren:"type_s:book",
filter:"{!filters param=$child.fq excludeTags=stars v=$childquery}"
},
type:terms,
field:stars_i,
facet:{
in_books:"unique(_root_)"
}
}
}
{code}
* *TODO* {{BJQParserFiltersTest}} should be collapsed with {{BJQParserTest}}
* -*TODO* edge case single child query is excluded.-
* -*TODO* assert parent scope filter exclusion along side with children ones-
Is there any concerns? -I think it may go in this week.-
was (Author: mkhludnev):
slightly refreshed [^SOLR_9510.patch].
* no changes in Lucene codebase
* it turns -a little bit- scary, however {{query}} facet is redundant. Anyway,
I can't see how to make it shorter:
{code:java}
q={!parent filters=$child.fq which=type_s:book v=$childquery}&
childquery=comment_t:*&
child.fq={!tag=author}author_s:dan&
child.fq={!tag=stars}stars_i:4&
json.facet={
comments_for_author:{
domain:{
excludeTags:author, // 1. rejoin child filters
and query, expand parents docset, apply parent filters (I suppose)
blockChildren:"type_s:book",// 2. join to expanded children
filter:"{!filters params=$child.fq excludeTags=author v=$childquery}"
// 3. filter them again
},
type:terms,
field:author_s,
facet:{
in_books:"unique(_root_)"
}
},
comments_for_stars:{
domain:{
excludeTags:stars,
blockChildren:"type_s:book",
filter:"{!filters params=$child.fq excludeTags=stars v=$childquery}"
},
type:terms,
field:stars_i,
facet:{
in_books:"unique(_root_)"
}
}
}
{code}
* *TODO* {{BJQParserFiltersTest}} should be collapsed with {{BJQParserTest}}
* -*TODO* edge case single child query is excluded.-
* -*TODO* assert parent scope filter exclusion along side with children ones-
Is there any concerns? -I think it may go in this week.-
> child level facet exclusions
>
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch, SOLR_9510.patch,
> SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up
> to parents, there is a demand for filter exclusions.
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this
> functionality rather than support a separate component.
> * During a discussion in SOLR-8998 a solution for block join with child
> level exclusion has been found.
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly,
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{{!parent}} query parser
> referring to _multiple_ filters queries via parameter name: {{{!parent
> filters=$child.fq ..}..=color:Red=size:XL}}
> these _filters_ are intersected with a child query supplied as a subordinate
> clause.
> * introducing \{{{!filters param=$child.fq excludeTags=color
> v=$subq}=text:word= \{!tag=color}color:Red=size:XL}}
> it intersects a subordinate clause (here it's {{subq}} param, and
[jira] [Updated] (SOLR-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9510:
---
Description:
h2. Challenge
* Since SOLR-5743 achieved block join child level facets with counts roll-up
to parents, there is a demand for filter exclusions.
h2. Context
* Then, it's worth to consider JSON Facets as an engine for this functionality
rather than support a separate component.
* During a discussion in SOLR-8998 a solution for block join with child level
exclusion has been found.
h2. Proposal
It's proposed to provide a bit of syntax sugar to make it user friendly,
believe it or not.
h2. List of improvements
* introducing a local parameter {{filters}} for {{{!parent}} query parser
referring to _multiple_ filters queries via parameter name: {{{!parent
filters=$child.fq ..}..=color:Red=size:XL}}
these _filters_ are intersected with a child query supplied as a subordinate
clause.
* introducing \{{{!filters param=$child.fq excludeTags=color
v=$subq}=text:word= \{!tag=color}color:Red=size:XL}} it
intersects a subordinate clause (here it's {{subq}} param, and the trick is to
refer to the same query from {{{!parent}}}), with multiple filters supplied via
parameter name {{param=$child.fq}}, it also supports {{excludeTags}}.
h2. Notes
Regarding the latter parser, the alternative approach might be to move into
{{domain:{..}}} instruction of json facet. From the implementation perspective,
it's desired to optimize with bitset processing, however I suppose it's might
be deferred until some initial level of maturity.
h2. Example
{code:java}
q={!parent which=type_s:book filters=$child.fq
v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
3)=json=on={
comments_for_author:{
type:query,
q:"{!filters param=$child.fq excludeTags=author v=$childquery}",
"//note":"author filter is excluded",
domain:{
blockChildren:"type_s:book",
"//":"applying filters here might be more promising"
}, facet:{
authors:{
type:terms,
field:author_s,
facet: {
in_books: "unique(_root_)"
}
}
}
} ,
comments_for_stars:{
type:query,
q:"{!filters param=$child.fq excludeTags=stars v=$childquery}",
"//note":"stars_i filter is excluded",
domain:{
blockChildren:"type_s:book"
}, facet:{
stars:{
type:terms,
field:stars_i,
facet: {
in_books: "unique(_root_)"
}
}
}
}
}
{code}
Votes? Opinions?
was:
h2. Challenge
* Since SOLR-5743 achieved block join child level facets with counts roll-up
to parents, there is a demand for filter exclusions.
h2. Context
* Then, it's worth to consider JSON Facets as an engine for this functionality
rather than support a separate component.
* During a discussion in SOLR-8998 a solution for block join with child level
exclusion has been found.
h2. Proposal
It's proposed to provide a bit of syntax sugar to make it user friendly,
believe it or not.
h2. List of improvements
* introducing a local parameter {{filters}} for {{{!parent}} query parser
referring to _multiple_ filters queries via parameter name: {{{!parent
filters=$child.fq ..}..=color:Red=size:XL}}
these _filters_ are intersected with a child query supplied as a subordinate
clause.
* introducing \{{{!filters param=$child.fq excludeTags=color
v=$subq}=text:word= \{!tag=color}color:Red=size:XL}} it
intersects a subordinate clause (here it's {{subq}} param, and the trick is to
refer to the same query from {{{!parent}}}), with multiple filters supplied via
parameter name {{param=$child.fq}}, it also supports {{excludeTags}}.
h2. Notes
Regarding the latter parser, the alternative approach might be to move into
{{domain:{..}}} instruction of json facet. From the implementation perspective,
it's desired to optimize with bitset processing, however I suppose it's might
be deferred until some initial level of maturity.
h2. Example
{code:java}
q={!parent which=type_s:book filters=$child.fq
v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
3)=json=on={
comments_for_author:{
type:query,
q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
"//note":"author filter is excluded",
domain:{
blockChildren:"type_s:book",
"//":"applying filters here might be more promising"
}, facet:{
authors:{
type:terms,
field:author_s,
facet: {
in_books: "unique(_root_)"
}
}
}
} ,
comments_for_stars:{
type:query,
q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
"//note":"stars_i filter is excluded",
domain:{
blockChildren:"type_s:book"
}, facet:{
stars:{
type:terms,
field:stars_i,
facet: {
in_books: "unique(_root_)"
}
}
}
}
}
{code}
Votes? Opinions?
> child level facet exclusions
>
[jira] [Created] (SOLR-12138) CLONE - AutoscalingHistoryHandlerTest fails frequently
Xijia Ding created SOLR-12138:
-
Summary: CLONE - AutoscalingHistoryHandlerTest fails frequently
Key: SOLR-12138
URL: https://issues.apache.org/jira/browse/SOLR-12138
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: AutoScaling
Reporter: Xijia Ding
Assignee: Andrzej Bialecki
Fix For: 7.3, master (8.0)
Attachments: tests-failures.txt
This test fails frequently on jenkins with a failed assertion (see also
SOLR-11378 for other failure mode):
{code}
[junit4] FAILURE 6.49s J2 | AutoscalingHistoryHandlerTest.testHistory <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<8> but
was:<6>
[junit4]>at
__randomizedtesting.SeedInfo.seed([164F10BB7F145FDE:7BB3B446C55CA0D9]:0)
[junit4]>at
org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:194)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{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-12096) Inconsistent response format in subquery transform
[
https://issues.apache.org/jira/browse/SOLR-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413161#comment-16413161
]
Lucene/Solr QA commented on SOLR-12096:
---
| (x) *{color:red}-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
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 13s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 34m 7s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 39m 12s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry |
| | solr.logging.TestLogWatcher |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12096 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916030/SOLR-12096.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8
21:10:42 UTC 2016 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 / 4bb02d8 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/17/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/17/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/17/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch,
> SOLR-12096.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared
> to single-shard
> h1. Single Shard collection
> Request
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt":
[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk1.8.0_144) - Build # 17 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/17/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.TestDistributedSearch.test
Error Message:
Expected to find shardAddress in the up shard info:
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException:
Time allowed to handle this request exceeded at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
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) ,time=1}
Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info:
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException:
Time allowed to handle this request exceeded
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
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)
,time=1}
at
__randomizedtesting.SeedInfo.seed([BEA4B20554C88A0A:36F08DDFFA34E7F2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1191)
at
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1132)
at
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:992)
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$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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
[jira] [Resolved] (SOLR-10119) TestReplicationHandler has always been too good at finding too many annoying bugs.
[ https://issues.apache.org/jira/browse/SOLR-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-10119. Resolution: Fixed > TestReplicationHandler has always been too good at finding too many annoying > bugs. > -- > > Key: SOLR-10119 > URL: https://issues.apache.org/jira/browse/SOLR-10119 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Attachments: SOLR-10119.patch, stdout, stdout > > > Fails a lot less in with SOLR-9903 in, but still 1-3 fails per 100 to look > into. -- 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/jdk1.8.0_162) - Build # 1591 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1591/ Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([5E063A7D2C2171ED:4FB2609A95A8651B]: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.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:253) 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 1784 lines...] [junit4] JVM J0: stdout was not empty, see:
[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413115#comment-16413115 ] Varun Thacker commented on SOLR-7887: - Thanks Erick! I'm looking at the patch right now. The two things I did right away was , click on "submit patch" so that the automatic build validation can run against the latest patch . Secondly I updated the reviewboard with the latest patch ( [https://reviews.apache.org/r/65888/diff/3/] ) > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-NightlyTests-7.3 - Build # 9 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/9/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetTest Error Message: Could not find collection:collection1 Stack Trace: java.lang.AssertionError: Could not find collection:collection1 at __randomizedtesting.SeedInfo.seed([C72488992B17EF55]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.analytics.SolrAnalyticsTestCase.setupCollection(SolrAnalyticsTestCase.java:63) 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$6.evaluate(RandomizedRunner.java:874) 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) FAILED: org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:51475: ADDREPLICA failed to create replica Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:51475: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([2A882B11FEF54604:A2DC14CB50092BFC]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.UnloadDistributedZkTest.testUnloadShardAndCollection(UnloadDistributedZkTest.java:125) at org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at
[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413111#comment-16413111 ] Erick Erickson commented on SOLR-7887: -- I think it's ready! [~hoss...@fucit.org]: I had to change a bit of ivy-versions.properties, /log4j/log4j is never referenced in the places like solr/core/ivy.xml after this patch and precommit failed. Specifically where you broke out the "org.log4j.major.version = 1.2". I made a trivial change but just in case it affects the javadoc builds I thought I'd call it out. - Upgraded to Log4J 2.11 rather than 2.10 since it's been released. - This requires LMAX-disruptor, which is licensed under Apache 2.0, but what should go in the disruptor-NOTICES.txt file? It's just a zero-byte file now. There is a disruptor-LICENSE-ASL.txt file with the full license. - jar-checksums, precommit and test targets all completed successfully, even after clearing out my ivy cache and doing a clean-jars I'll commit this later today so we can start getting some mileage on it. > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-10075) Move assumes in TestNonWritablePersistFile to BeforeClass method.
[ https://issues.apache.org/jira/browse/SOLR-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-10075: --- Priority: Minor (was: Major) > Move assumes in TestNonWritablePersistFile to BeforeClass method. > - > > Key: SOLR-10075 > URL: https://issues.apache.org/jira/browse/SOLR-10075 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: SOLR-10075.patch > > -- 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] (SOLR-10075) Move assumes in TestNonWritablePersistFile to BeforeClass method.
[ https://issues.apache.org/jira/browse/SOLR-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-10075. Resolution: Fixed Actually I guess I can keep this class and use tests.ifNoTests sys prop. I don't like that this test is the only one we have that requires that you are not a super user, I think that is a bad precedent, but really I just want it off the top of the list of bad tests in the test report. I'll just rename this JIRA to moving the assumptions to a before class method. > Move assumes in TestNonWritablePersistFile to BeforeClass method. > - > > Key: SOLR-10075 > URL: https://issues.apache.org/jira/browse/SOLR-10075 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: SOLR-10075.patch > > -- 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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-7887: - Attachment: SOLR-7887.patch > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-10075) Move assumes in TestNonWritablePersistFile to BeforeClass method.
[ https://issues.apache.org/jira/browse/SOLR-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-10075: --- Summary: Move assumes in TestNonWritablePersistFile to BeforeClass method. (was: TestNonWritablePersistFile fails when run as a single test under root.) > Move assumes in TestNonWritablePersistFile to BeforeClass method. > - > > Key: SOLR-10075 > URL: https://issues.apache.org/jira/browse/SOLR-10075 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: SOLR-10075.patch > > -- 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] [Reopened] (SOLR-10075) TestNonWritablePersistFile fails when run as a single test under root.
[ https://issues.apache.org/jira/browse/SOLR-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-10075: Turns out putting assume in before class doesn't help this issue as all. This test will still fail when run as a single test when the assumptions fail. This is the only test out of 1100+ that fails this way when run with admin privileges. I think this test should be ignored until it can be implemented in a non privilege sensitive way, but for now I'm just going to exclude it from all test reports. > TestNonWritablePersistFile fails when run as a single test under root. > -- > > Key: SOLR-10075 > URL: https://issues.apache.org/jira/browse/SOLR-10075 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: SOLR-10075.patch > > -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved LUCENE-8220. - Resolution: Fixed Fix Version/s: master (8.0) 7.4 6.7 > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Fix For: 6.7, 7.4, master (8.0) > > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413093#comment-16413093 ] ASF subversion and git services commented on LUCENE-8220: - Commit a13befe7580c93b8721a4680b8208de3b8c49d5e in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a13befe ] LUCENE-8220: Add general makeGeoPolygon variant that decides the best technology for you. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413092#comment-16413092 ] ASF subversion and git services commented on LUCENE-8220: - Commit 93140c0c21d2b4bea9be4ddf00629f23bc936667 in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93140c0 ] LUCENE-8220: Add general makeGeoPolygon variant that decides the best technology for you. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413091#comment-16413091 ] ASF subversion and git services commented on LUCENE-8220: - Commit 85c182607b5bf233d6eda3ac3fbe4d122ac99cd7 in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=85c1826 ] LUCENE-8220: Add general makeGeoPolygon variant that decides the best technology for you. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-Linux (64bit/jdk-9.0.4) - Build # 21698 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21698/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew Error Message: expected:<200> but was:<403> Stack Trace: java.lang.AssertionError: expected:<200> but was:<403> at __randomizedtesting.SeedInfo.seed([CCABEC2F1B2D49D:3B514ADCC97E0939]: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.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:132) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:316) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:333) 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
[GitHub] lucene-solr issue #342: SOLR-12120: New AuditLoggerPlugin type allowing cust...
Github user tflobbe commented on the issue: https://github.com/apache/lucene-solr/pull/342 LGTM, thanks for addressing my comments --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12137) Create Windows-equivalent of bin-test/test
Jason Gerlowski created SOLR-12137:
--
Summary: Create Windows-equivalent of bin-test/test
Key: SOLR-12137
URL: https://issues.apache.org/jira/browse/SOLR-12137
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Components: scripts and tools
Affects Versions: master (8.0)
Reporter: Jason Gerlowski
SOLR-11749 introduced a regression suite for the {{bin/solr}} scripts.
Currently this suite (located in {{solr/bin-test}} only covers the *nix copy of
{{bin/solr}}. No tests are run for the Windows version.
This JIRA involves porting the existing {{bin-test/test}} logic (along with the
accompanying tests) to Windows batch. This will allow both version of the
script to be tested.
--
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-11749) regression-test-like functionality for bin/solr*
[
https://issues.apache.org/jira/browse/SOLR-11749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413046#comment-16413046
]
Jason Gerlowski commented on SOLR-11749:
Was thinking about next steps for this test suite, and there's a lot of
branches that I'd like this to go in.
- expand test coverage for other {{bin/solr}} tools (auth, zk, assert,
start/stop/restart).
- add Windows equivalent functionality
- minor test harness/runner improvements (add verbosity controls, etc.)
- performance improvements (currently the suite takes too long to run to make
it practical to run on normal builds).
- integrate with {{ant test}} target
I plan on writing up JIRA issues for each of these, and using this issue as a
parent/umbrella for the remaining functionality that I think is still
low-hanging fruit here. That should make it easy for others to pitch in too if
they feel the urge.
> regression-test-like functionality for bin/solr*
>
>
> Key: SOLR-11749
> URL: https://issues.apache.org/jira/browse/SOLR-11749
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Christine Poerschke
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-11749.patch, SOLR-11749.patch, SOLR-11749.patch,
> SOLR-11749.patch, SOLR-11749.patch, test-output.txt
>
>
--
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-MacOSX (64bit/jdk1.8.0) - Build # 534 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/534/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testScheduledTrigger Error Message: null Live Nodes: [127.0.0.1:54946_solr, 127.0.0.1:54958_solr] Last available state: null Stack Trace: java.lang.AssertionError: null Live Nodes: [127.0.0.1:54946_solr, 127.0.0.1:54958_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([F0AAEB8940AB1E8D:63B1A3FB1E5645B9]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testScheduledTrigger(TriggerIntegrationTest.java:1669) 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) FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue Error Message:
[JENKINS] Lucene-Solr-repro - Build # 331 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/331/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/8/consoleText [repro] Revision: eb8a5a882f879a51389b5d43f74f3aceac9e68c9 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=RestartWhileUpdatingTest -Dtests.method=test -Dtests.seed=35E4462731FA2D32 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=hu-HU -Dtests.timezone=America/Mexico_City -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=RestartWhileUpdatingTest -Dtests.seed=35E4462731FA2D32 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=hu-HU -Dtests.timezone=America/Mexico_City -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CloudSolrClientTest -Dtests.method=preferLocalShardsTest -Dtests.seed=8919D6D03F11CB6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=be-BY -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=StreamExpressionTest -Dtests.method=testParallelExecutorStream -Dtests.seed=8919D6D03F11CB6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=lt-LT -Dtests.timezone=Europe/Ulyanovsk -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=StreamExpressionTest -Dtests.method=testCopyOfRange -Dtests.seed=8919D6D03F11CB6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=lt-LT -Dtests.timezone=Europe/Ulyanovsk -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: bbf8306615aa87d12f52113587140fb792d93cd5 [repro] git fetch [repro] git checkout eb8a5a882f879a51389b5d43f74f3aceac9e68c9 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/solrj [repro] StreamExpressionTest [repro] CloudSolrClientTest [repro]solr/core [repro] RestartWhileUpdatingTest [repro] ant compile-test [...truncated 2460 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.StreamExpressionTest|*.CloudSolrClientTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.seed=8919D6D03F11CB6 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=lt-LT -Dtests.timezone=Europe/Ulyanovsk -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 980 lines...] [repro] ant compile-test [...truncated 1331 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.RestartWhileUpdatingTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.seed=35E4462731FA2D32 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt -Dtests.locale=hu-HU -Dtests.timezone=America/Mexico_City -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 64416 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.client.solrj.impl.CloudSolrClientTest [repro] 0/5 failed: org.apache.solr.client.solrj.io.stream.StreamExpressionTest [repro] 2/5 failed: org.apache.solr.cloud.RestartWhileUpdatingTest [repro] git checkout bbf8306615aa87d12f52113587140fb792d93cd5 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8220) GeoPolygon factory still shows problems with coplanar points
[
https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413021#comment-16413021
]
Ignacio Vera edited comment on LUCENE-8220 at 3/25/18 1:15 PM:
---
I wanted to file a Jira ticket to add such a factory method, something like
{{makeBestGeoPolygon}} and even offer the user to input the cut over if they
want to do so.
This would be great as it could be used is the Geo3d wrapper!
I wonder if to avoid changing too much existing API, we might want to allow the
current factory method {{makeGeoPolygon}} to fail in case of a tile exception
and move the failover to the new factory method that does what you explain
above.
was (Author: ivera):
I wanted to file a Jira ticket to add such a factory method, something like
{{makeBestGeoPolygon}} and even offer the user to input the cut over if they
want to do so.
This would be great as it could be used is the Geo3d wrapper!
I wonder if to avoid changing too much existing API, we should allow the
factory method {{makeGeoPolygon}} fail with a tile exception (nice, it can be
recognized) and move the failover to a new factory method that does what you
explain above.
> GeoPolygon factory still shows problems with coplanar points
>
>
> Key: LUCENE-8220
> URL: https://issues.apache.org/jira/browse/LUCENE-8220
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: concave.jpg, concaveWithTiling.jpg,
> coplanarity-test.patch, factory.patch
>
>
> The attached patch contains two polygons that still shows problems with
> co-planar points. To better explain the issue I attached some images:
> 1) concave.jpg: This is the polygon we want to build. Note that we want to
> build the concave part, therefore the blue part is actually not part of the
> shape and the white part is the area cover by the shape.
> 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile
> the polygon using convex polygons. In our case it creates the three colored
> polygons on the image. What it remains is a concave polygon.
> The problem with this polygon is that the right edge of the concave polygon
> contains co-planar points. These points cannot be merged into a single plane
> because they have different properties (internal edges or shape edges).
> Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with
> co-planar points, the polygon cannot be built.
> [~kwri...@metacarta.com], Is it possible to make this polygons support such
> an extreme case?
--
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-8220) GeoPolygon factory still shows problems with coplanar points
[
https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413021#comment-16413021
]
Ignacio Vera commented on LUCENE-8220:
--
I wanted to file a Jira ticket to add such a factory method, something like
{{makeBestGeoPolygon}} and even offer the user to input the cut over if they
want to do so.
This would be great as it could be used is the Geo3d wrapper!
I wonder if to avoid changing too much existing API, we should allow the
factory method {{makeGeoPolygon}} fail with a tile exception (nice, it can be
recognized) and move the failover to a new factory method that does what you
explain above.
> GeoPolygon factory still shows problems with coplanar points
>
>
> Key: LUCENE-8220
> URL: https://issues.apache.org/jira/browse/LUCENE-8220
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: concave.jpg, concaveWithTiling.jpg,
> coplanarity-test.patch, factory.patch
>
>
> The attached patch contains two polygons that still shows problems with
> co-planar points. To better explain the issue I attached some images:
> 1) concave.jpg: This is the polygon we want to build. Note that we want to
> build the concave part, therefore the blue part is actually not part of the
> shape and the white part is the area cover by the shape.
> 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile
> the polygon using convex polygons. In our case it creates the three colored
> polygons on the image. What it remains is a concave polygon.
> The problem with this polygon is that the right edge of the concave polygon
> contains co-planar points. These points cannot be merged into a single plane
> because they have different properties (internal edges or shape edges).
> Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with
> co-planar points, the polygon cannot be built.
> [~kwri...@metacarta.com], Is it possible to make this polygons support such
> an extreme case?
--
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 # 2449 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2449/ 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew Error Message: expected:<200> but was:<403> Stack Trace: java.lang.AssertionError: expected:<200> but was:<403> at __randomizedtesting.SeedInfo.seed([C248ADCAF6254E1B:F5D359D4CEE993BF]: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.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:132) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:316) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:333) 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
[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk-9.0.4) - Build # 64 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/64/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest Error Message: 7 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 1) Thread[id=15209, name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[A7F6B0BFFE7216F]-EventThread, state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.4/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.4/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)2) Thread[id=15609, name=zkCallback-4998-thread-4, state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.4/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462) at java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361) at java.base@9.0.4/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)3) Thread[id=15210, name=zkConnectionManagerCallback-4999-thread-1, state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.4/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.4/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)4) Thread[id=15610, name=zkCallback-4998-thread-5, state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.4/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462) at java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361) at java.base@9.0.4/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)5) Thread[id=15208, name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[A7F6B0BFFE7216F]-SendThread(127.0.0.1:37881), state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/java.lang.Thread.sleep(Native Method) at app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105) at app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000) at app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)6) Thread[id=15207, name=Connection evictor, state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at java.base@9.0.4/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at
[jira] [Commented] (LUCENE-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413012#comment-16413012 ] Karl Wright commented on LUCENE-8220: - [~ivera] Switchover code has been implemented and committed, and the tests enabled. The only remaining concerns are as follows: (1) The API for makeGeoPolygon() accepts holes as other GeoPolygons. This is incompatible with GeoComplexPolygon, so I've disabled the cutover in the case where holes are present. The right thing to do in any case is create a new variant of the makeGeoPolygon() method that accepts holes as a list of PolygonDescription objects, and builds them itself. We'd want to deprecate the old method also. (2) It's also plausible now to automatically decide, based on number of points, whether we want to cut over to GeoComplexPolygon based on polygon complexity. We may want to implement a cutover automatically at (say) 100 points, just for performance reasons. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-8202. --- Resolution: Fixed > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4 > > Attachments: LUCENE-8202-fixes.patch, LUCENE-8202.patch, > LUCENE-8202.patch, LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- 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-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413010#comment-16413010 ] ASF subversion and git services commented on LUCENE-8202: - Commit 7e4358046eaf9c887ef3037f9ba3460b6bae5f06 in lucene-solr's branch refs/heads/branch_7x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e43580 ] LUCENE-8202: Fix positionlength for FixedShingleFilter and add limits to shingle size and count > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4 > > Attachments: LUCENE-8202-fixes.patch, LUCENE-8202.patch, > LUCENE-8202.patch, LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- 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-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413011#comment-16413011 ] ASF subversion and git services commented on LUCENE-8202: - Commit bbf8306615aa87d12f52113587140fb792d93cd5 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bbf8306 ] LUCENE-8202: Fix positionlength for FixedShingleFilter and add limits to shingle size and count > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4 > > Attachments: LUCENE-8202-fixes.patch, LUCENE-8202.patch, > LUCENE-8202.patch, LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- 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-12088) Shards with dead replicas cause increased write latency
[
https://issues.apache.org/jira/browse/SOLR-12088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413009#comment-16413009
]
Cao Manh Dat commented on SOLR-12088:
-
Since this seems to relate to LIR only, so the solution for this issue so far
is fixing {{ZkController.ensureReplicaInLeaderInitiatedRecovery}} to skip
adding an LIR thread in case of replica get deleted.
> Shards with dead replicas cause increased write latency
> ---
>
> Key: SOLR-12088
> URL: https://issues.apache.org/jira/browse/SOLR-12088
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Priority: Major
>
> If a collection's shard contains dead replicas, write latency to the
> collection is increased. For example, if a collection has 10 shards with a
> replication factor of 3, and one of those shards contains 3 replicas and 3
> downed replicas, write latency is increased in comparison to a shard that
> contains only 3 replicas.
> My feeling here is that downed replicas should be completely ignored and not
> cause issues to other alive replicas in terms of write latency.
--
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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413008#comment-16413008 ] ASF subversion and git services commented on LUCENE-8220: - Commit 81ac4d28fb9eacfe80a9ce9e880b5592ea51e363 in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81ac4d2 ] LUCENE-8220: Switch over to using GeoComplexPolygon if we can't tile a polygon. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413007#comment-16413007 ] ASF subversion and git services commented on LUCENE-8220: - Commit 9b0721be32eea98f8d32fd1d0e5c26e7af1201b0 in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b0721b ] LUCENE-8220: Switch over to using GeoComplexPolygon if we can't tile a polygon. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413006#comment-16413006 ] Alan Woodward commented on LUCENE-8202: --- I've attached the bugfix patch for reference. > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4 > > Attachments: LUCENE-8202-fixes.patch, LUCENE-8202.patch, > LUCENE-8202.patch, LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413005#comment-16413005 ] ASF subversion and git services commented on LUCENE-8220: - Commit 273a829c465a539de66049713ffb5ea58dd2278a in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=273a829 ] LUCENE-8220: Switch over to using GeoComplexPolygon if we can't tile a polygon. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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] (LUCENE-8202) Add a FixedShingleFilter
[ https://issues.apache.org/jira/browse/LUCENE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8202: -- Attachment: LUCENE-8202-fixes.patch > Add a FixedShingleFilter > > > Key: LUCENE-8202 > URL: https://issues.apache.org/jira/browse/LUCENE-8202 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4 > > Attachments: LUCENE-8202-fixes.patch, LUCENE-8202.patch, > LUCENE-8202.patch, LUCENE-8202.patch > > > In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and > emit arbitrary graphs, while duplicating all the functionality of the > existing ShingleFilter. This ends up being extremely hairy, and doesn't play > well with query parsers. > I'd like to step back and try and create a simpler shingle filter that can be > used for index-time phrase tokenization only. It will have a single fixed > shingle size, can deal with single-token synonyms, and won't emit unigrams. -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412999#comment-16412999 ] Ignacio Vera commented on LUCENE-8220: -- For the concave issue I have already thought about that as there is no obvious solution with tiling. Even more, tiling is expected to have limitations when points are very close together. Checks for problematic polygons look good, so +1 for a backoff strategy. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412997#comment-16412997 ] Karl Wright commented on LUCENE-8220: - The more I look at this, the more I think having a "use GeoComplexPolygon as a backoff" strategy is the right thing to do. I've committed some code cleanup designed to simplify the process of implementing that. I'll be doing more such cleanup as I implement. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412994#comment-16412994 ] ASF subversion and git services commented on LUCENE-8220: - Commit 88b057025024521be21c3c32b32fc1cd14b141f2 in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=88b0570 ] LUCENE-8220: Code cleanup in preparation for returning GeoComplexPolygon as an alternative instead of tiling. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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+5) - Build # 21697 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21697/ Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger Error Message: expected:<3> but was:<2> Stack Trace: java.lang.AssertionError: expected:<3> but was:<2> at __randomizedtesting.SeedInfo.seed([F2A63090E853CBC:6CE1558B974A4F91]: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.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:112) at org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:65) 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:841) Build Log:
[jira] [Commented] (LUCENE-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412993#comment-16412993 ] ASF subversion and git services commented on LUCENE-8220: - Commit f8b7399bb68e3fad4f2748db3e3633e040f9d6cc in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f8b7399 ] LUCENE-8220: Code cleanup in preparation for returning GeoComplexPolygon as an alternative instead of tiling. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412992#comment-16412992 ] ASF subversion and git services commented on LUCENE-8220: - Commit 5e1d6f36f71b693096c687cd4753847c2a8c107c in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e1d6f3 ] LUCENE-8220: Code cleanup in preparation for returning GeoComplexPolygon as an alternative instead of tiling. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-NightlyTests-7.x - Build # 182 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/182/ 1 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1 Error Message: Unexpected status: HTTP/1.1 400 Bad Request Stack Trace: java.lang.AssertionError: Unexpected status: HTTP/1.1 400 Bad Request at __randomizedtesting.SeedInfo.seed([9B1801223018C787:B8A980420D72C550]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AliasIntegrationTest.assertSuccess(AliasIntegrationTest.java:320) at org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1(AliasIntegrationTest.java:253) 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 1808 lines...] [junit4] JVM J0: stdout was not empty, see: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp/junit4-J0-20180325_051855_1757650369699112098039.sysout [junit4] >>> JVM
[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 518 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/518/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 14 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:61989/_/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:61989/_/collection1 at __randomizedtesting.SeedInfo.seed([18C6ABB7085355A5:9092946DA6AF385D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1591) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:212) 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:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) 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
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1589 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412936#comment-16412936 ] Karl Wright commented on LUCENE-8220: - I think some of the communication disconnect we have been having is due to the fact that I'm thinking that tiling of GeoConvexPolygon and GeoConcavePolygon is really only applicable to polygons whose edges are fairly long to start with. Polygons whose edge points are very close together is not the expected use case of this approach; that is what GeoComplexPolygon is for. The problem you demonstrate can still occur in a larger-scale polygon, but only if there's a chance alignment between one edge and a point on the other side of the polygon. My thinking, and the code I've committed is meant to deal with that specific failure case, and not the case where the tinyness of the polygon prevents *all* possible new edges from being created. I still have no idea how to solve that problem. It may be worth having the exception that is currently thrown recommend using GeoComplexPolygon instead. Or, maybe the factory should automatically choose that representation if we see that situation arise. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412935#comment-16412935 ] ASF subversion and git services commented on LUCENE-8220: - Commit 9bd84fccd6af3a1ecf586acebfa5c0dd8a33755e in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9bd84fc ] LUCENE-8220: need a continue, not a break > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412933#comment-16412933 ] ASF subversion and git services commented on LUCENE-8220: - Commit 67572cf6d3127df3e749019bfcdcef97c738c6b1 in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=67572cf ] LUCENE-8220: need a continue, not a break > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412932#comment-16412932 ] ASF subversion and git services commented on LUCENE-8220: - Commit 9e5468adcd156f6ff2592d8607afd83f7303a860 in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9e5468a ] LUCENE-8220: need a continue, not a break > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412929#comment-16412929 ] Ignacio Vera commented on LUCENE-8220: -- The patch proves that problems arise when co-planar points are added into the edge buffer. The replace method of the edge buffer merges those situations into one single edge. The problem is that the merged edges can have different internal flags. In the patch the value for the merged edge is false if any of the edges is not internal. In the concave case, the polygon can be built but it is not fully correct as the edge of one convex tile has been merged and it has wrong internal flag (right vertical edge in concaveWithtiling.jpg). This is a generic problem whenever edges are merged this way, that is the reason one of the test is failing now, because of a merged edge. When collecting points prior to build the final GeoConcavePolygon or GeoConvexPolygon, we can detect those situations and do something about it. In the convex case, further divide the edges, not sure in the concave case. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412927#comment-16412927 ] ASF subversion and git services commented on LUCENE-8220: - Commit 87feabaee2fff063692ceb9a1e108c6e9e41b9d0 in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=87feaba ] LUCENE-8220: Refine how handle tiling coplanarities further. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412926#comment-16412926 ] ASF subversion and git services commented on LUCENE-8220: - Commit fbeb3a4b682fdf290a3de4e865ce089f5657b4e8 in lucene-solr's branch refs/heads/branch_7x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fbeb3a4 ] LUCENE-8220: Refine how handle tiling coplanarities further. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412924#comment-16412924 ] ASF subversion and git services commented on LUCENE-8220: - Commit d49ba5c333d06953b323ba18b133e706d9d06fc3 in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d49ba5c ] LUCENE-8220: Refine how handle tiling coplanarities further. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-8220) GeoPolygon factory still shows problems with coplanar points
[ https://issues.apache.org/jira/browse/LUCENE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412923#comment-16412923 ] Karl Wright commented on LUCENE-8220: - [~ivera], I now understand why the GeoConcavePolygon construction failed: my check for whether a usable tiling had been found or not was in the wrong place. So that mystery is cleared up, and I'll commit new code right now to address that. But the tiling does not complete still with the right change, because the only choices for edges to split the (non-concave) polygon all indeed yield effectively colinear edges in this example. Indeed, I agree this is theoretically possible during the tiling process whenever a new edge is created. Polygons with very-close-together edge points that nevertheless cover significant area are susceptible to this issue. In order for the tiling to work, edges that are created for tiling must be labeled "internal", and we must use exactly the same edge for both tiles that the edge is involved with. It looks like your earlier patches achieve that by just making sure we don't pick a tiling that doesn't work. Am I correct in this? I'm beginning to at least understand the philosophy behind keeping "extended edges" around. I'm still unsure that has the potential to solve the general problem, though. > GeoPolygon factory still shows problems with coplanar points > > > Key: LUCENE-8220 > URL: https://issues.apache.org/jira/browse/LUCENE-8220 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: concave.jpg, concaveWithTiling.jpg, > coplanarity-test.patch, factory.patch > > > The attached patch contains two polygons that still shows problems with > co-planar points. To better explain the issue I attached some images: > 1) concave.jpg: This is the polygon we want to build. Note that we want to > build the concave part, therefore the blue part is actually not part of the > shape and the white part is the area cover by the shape. > 2) concaveWithTiling.jpg: The algorithm of the polygon factory tries to tile > the polygon using convex polygons. In our case it creates the three colored > polygons on the image. What it remains is a concave polygon. > The problem with this polygon is that the right edge of the concave polygon > contains co-planar points. These points cannot be merged into a single plane > because they have different properties (internal edges or shape edges). > Because GeoConvexPolygon and GeoConcavePolygon cannot handle polygons with > co-planar points, the polygon cannot be built. > [~kwri...@metacarta.com], Is it possible to make this polygons support such > an extreme case? -- 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-repro - Build # 327 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/327/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/181/consoleText [repro] Revision: 56009132b99472adcdaf47a1ddd61afaa93cf88a [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=FullSolrCloudDistribCmdsTest -Dtests.method=test -Dtests.seed=2EB3298AB2A83A44 -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=sr-BA -Dtests.timezone=SystemV/YST9 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=FullSolrCloudDistribCmdsTest -Dtests.seed=2EB3298AB2A83A44 -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=sr-BA -Dtests.timezone=SystemV/YST9 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: ea504091e517b5a2941b76adef7270b3d6ecb34c [repro] git fetch [repro] git checkout 56009132b99472adcdaf47a1ddd61afaa93cf88a [...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] FullSolrCloudDistribCmdsTest [repro] ant compile-test [...truncated 3314 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.FullSolrCloudDistribCmdsTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.seed=2EB3298AB2A83A44 -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=sr-BA -Dtests.timezone=SystemV/YST9 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 49424 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java -ea -esa -Dtests.prefix=tests -Dtests.seed=2EB3298AB2A83A44 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=sr-BA -Dtests.timezone=SystemV/YST9 -Dtests.directory=random -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt -Dtests.luceneMatchVersion=7.4.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/tools/junit4/logging.properties -Dtests.nightly=true -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp -Djava.io.tmpdir=./temp -Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/solr/build/solr-core/test/temp -Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene -Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/build/clover/db -Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/tools/junit4/solr-tests.policy -Dtests.LUCENE_VERSION=7.4.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/solr/core -Djava.security.egd=file:/dev/./urandom -Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/solr/build/solr-core/test/J1 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false -Dtests.filterstacks=true -Dtests.maxfailures=5 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dfile.encoding=ISO-8859-1 -classpath
