[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_72) - Build # 295 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/295/ Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestAuthenticationFramework.testStopAllStartAll Error Message: Address already in use Stack Trace: java.net.BindException: Address already in use at __randomizedtesting.SeedInfo.seed([76CF74DB724CC61E:F16BA8337B6B31]:0) at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326) at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80) at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.server.Server.doStart(Server.java:384) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:327) at org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:356) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:443) 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:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) 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
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217413#comment-15217413
]
Noble Paul commented on SOLR-8914:
--
bq.I guess that's not true anymore because the watcher invocations are done
asynchronously via a thread pool in Solr. So the original guarantees made by ZK
don't apply anymore?
+1 shalin. Even if ZK does the event loop in a single thread, it fires the
callback into {{SolrZkClient.zkCallbackExecutor}} threadpool . So that single
thread is free to fire more callbacks. So, we cannot guarantee thread safety in
any watcher callback functions
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch, SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217379#comment-15217379
]
Shalin Shekhar Mangar commented on SOLR-8914:
-
I'm still digesting the discussions in this thread but..
bq. ...and one of my implicit assumptions that was that any given watcher would
not get re-fired until the previous watcher invocation had returned. But maybe
that was a really bad assumption that I carried over from Curator, or perhaps
the thread model in ZK has changed?
I guess that's not true anymore because the watcher invocations are done
asynchronously via a thread pool in Solr. So the original guarantees made by ZK
don't apply anymore?
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch, SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 1050 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1050/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, SolrCore, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, SolrCore, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([6F9D598323A0D2E7]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238) at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) 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:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=1749, name=searcherExecutor-924-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=1749, name=searcherExecutor-924-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([6F9D598323A0D2E7]:0) FAILED:
[jira] [Updated] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8914:
---
Attachment: SOLR-8914.patch
I wrote up a stress test to demonstrate the bug. I've added it to the patch
Scott already worked up & attached.
Scott: Prior to incorporating your changes, hammering on this stress test would
fail within the first 20 attempts. But with your changes I'm seeing deadlocks
within the first 5 attempts every time i hammer on it...
{noformat}
Found one Java-level deadlock:
=
"zkCallback-7-thread-2-processing-n:127.0.0.1:48312_solr":
waiting to lock monitor 0x7f82d40076b8 (object 0xff3b5b38, a
java.lang.Object),
which is held by "zkCallback-7-thread-1-processing-n:127.0.0.1:48312_solr"
"zkCallback-7-thread-1-processing-n:127.0.0.1:48312_solr":
waiting to lock monitor 0x7f82d400be38 (object 0xff3b5800, a
org.apache.solr.common.cloud.ZkStateReader),
which is held by
"OverseerStateUpdate-95637266046386179-127.0.0.1:48312_solr-n_00"
"OverseerStateUpdate-95637266046386179-127.0.0.1:48312_solr-n_00":
waiting to lock monitor 0x7f82d40076b8 (object 0xff3b5b38, a
java.lang.Object),
which is held by "zkCallback-7-thread-1-processing-n:127.0.0.1:48312_solr"
{noformat}
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch, SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller closed SOLR-5604. - Resolution: Duplicate > Remove deprecations caused by httpclient 4.3.x upgrade > -- > > Key: SOLR-5604 > URL: https://issues.apache.org/jira/browse/SOLR-5604 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.7 >Reporter: Shawn Heisey > Fix For: master, 4.9 > > Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch > > > SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This > version deprecates a LOT of classes and methods, recommending that they all > be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Move to non deprecated HttpClient impl classes to remove stale connection check on every request and move connection lifecycle management towards the client.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4509: -- Attachment: 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch Patch after first pass of review and cleanup. > Move to non deprecated HttpClient impl classes to remove stale connection > check on every request and move connection lifecycle management towards the > client. > - > > Key: SOLR-4509 > URL: https://issues.apache.org/jira/browse/SOLR-4509 > Project: Solr > Issue Type: Improvement > Components: search > Environment: 5 node SmartOS cluster (all nodes living in same global > zone - i.e. same physical machine) >Reporter: Ryan Zezeski >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, master > > Attachments: > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > baremetal-stale-nostale-med-latency.dat, > baremetal-stale-nostale-med-latency.svg, > baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg > > > By disabling the Apache HTTP Client stale check I've witnessed a 2-4x > increase in throughput and reduction of over 100ms. This patch was made in > the context of a project I'm leading, called Yokozuna, which relies on > distributed search. > Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 > Here's a write-up I did on my findings: > http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html > I'm happy to answer any questions or make changes to the patch to make it > acceptable. > ReviewBoard: https://reviews.apache.org/r/28393/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 25 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/25/ 4 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBufferOnNonLeader Error Message: Captured an uncaught exception in thread: Thread[id=102044, name=cdcr-replicator-5816-thread-1, state=RUNNABLE, group=TGRP-CdcrReplicationDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=102044, name=cdcr-replicator-5816-thread-1, state=RUNNABLE, group=TGRP-CdcrReplicationDistributedZkTest] at __randomizedtesting.SeedInfo.seed([2EDAC8600D29B3B2:2E90C7575B19CB38]:0) Caused by: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([2EDAC8600D29B3B2]:0) at org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:609) at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:120) at org.apache.solr.handler.CdcrReplicatorScheduler$1.run(CdcrReplicatorScheduler.java:83) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:59046/neg Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:59046/neg at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:381) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:497) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:169) 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:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at
[jira] [Commented] (SOLR-1898) Improved reporting of exceptions during indexing
[
https://issues.apache.org/jira/browse/SOLR-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217317#comment-15217317
]
Shyam commented on SOLR-1898:
-
+1, specifying the field which was the source of issue is definite bonus
> Improved reporting of exceptions during indexing
>
>
> Key: SOLR-1898
> URL: https://issues.apache.org/jira/browse/SOLR-1898
> Project: Solr
> Issue Type: Improvement
>Reporter: Grant Ingersoll
> Labels: newdev
>
> Recently indexing some data where I had mismatched types going in (schema was
> an int, I was sending in a float) and got:
> {code}
> Apr 30, 2010 3:48:46 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NumberFormatException: For input string: "0.0"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:458)
> at java.lang.Integer.parseInt(Integer.java:499)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:426)
> {code}
> I think our indexing exception handling needs to add at least two things (we
> also need per document handling of errors during batch, but that is covered
> by SOLR-445, see also SOLR-482)
> 1. If there was an error creating the field, the exception should specify
> what the field name is.
> 2. All document exceptions should, if there is a unique key, report the
> unique key of the document that failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7094) spatial-extras BBoxStrategy and (confusingly!) PointVectorStrategy use legacy numeric encoding
[ https://issues.apache.org/jira/browse/LUCENE-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-7094: - Attachment: LUCENE_7094.patch Both BBoxStrategy & PointVectorStrategy: * all state is now final; setters are removed. The constructor has everything it needs to know. The constructor is public, and represents an alternative to the static factory methods you added, for when the caller has options to customize. *Perhaps instead this should be another factory method?* * Options are set via a passed FieldType; and there’s a getter for it. * The code for state, construction & createFields are very consistent now. It’s a bit dejavu but it’s not clear refactoring to reduce duplication would be worthwhile. * no special name prefix is needed for DocValues based field. (same as it has been) * some javadocs updates; remove references to legacy numerics BBoxStrategy: * the internal ComboField is gone PointVectorStrategy: * consistency with BBoxStrategy now means this has some options formerly only in BBoxStrategy: can be marked stored (default false), the index (be it PointValues or legacy numeric) is optional (default true), and DocValues is optional (default true). An error is thrown if you call makeQuery and there’s no index. Tests: * Added test for being able to turn stored on/off, the index on/off on PointVectorStrategy * removed automatic use of UninvertedField, and the needsDocValues overrideable method. Instead I added a utility method a test can invoke to introduce UninvertedField with the specified list of fields and the UninvertedField.Type (thus enabling testing uninverting of Double PointValues)). _I know we said this could be another issue but it didn't take long and it's comforting to see it works_ * TestBBoxStrategy now tests uninverting behavior and for both legacy & pointValues Misc: * No changes to SpatialStrategy > spatial-extras BBoxStrategy and (confusingly!) PointVectorStrategy use legacy > numeric encoding > -- > > Key: LUCENE-7094 > URL: https://issues.apache.org/jira/browse/LUCENE-7094 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Nicholas Knize >Priority: Blocker > Fix For: master, 6.0 > > Attachments: LUCENE-7094.patch, LUCENE-7094.patch, LUCENE_7094.patch, > LUCENE_7094.patch > > > We need to deprecate these since they work on the old encoding and provide > points based alternatives. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2987) QueryParser throwing null pointer exception if input is invalid
[ https://issues.apache.org/jira/browse/LUCENE-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217305#comment-15217305 ] Shyam commented on LUCENE-2987: --- do we still want to pursue this? > QueryParser throwing null pointer exception if input is invalid > --- > > Key: LUCENE-2987 > URL: https://issues.apache.org/jira/browse/LUCENE-2987 > Project: Lucene - Core > Issue Type: Bug > Components: core/queryparser >Affects Versions: 3.0.2 >Reporter: Ramesh > Labels: newdev > Attachments: LUCENE-2987.patch > > > I was using org.apache.lucene.queryParser.QueryParser for parsing the input. > My input: > Input query string: "category: (4 or 6 or 8)" > Analyzer: StandardAnalyzer > QueryParser's parse() method is resulting in Null Pointer Exception. > If i give input query string as "category: (4 OR 6 OR 8)" which is uppercase > 'OR', it works fine and i get the desired results. > I'm seeing the problem only with lower case 'or' -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+111-patched) - Build # 16378 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16378/
Java: 32bit/jdk-9-ea+111-patched -client -XX:+UseG1GC -XX:-CompactStrings
1 tests failed.
FAILED: org.apache.solr.handler.TestReqParamsAPI.test
Error Message:
Could not get expected value 'CY val' for path 'params/c' full output: {
"responseHeader":{ "status":0, "QTime":0}, "params":{ "a":"A
val", "b":"B val", "wt":"json", "useParams":""}, "context":{
"webapp":"", "path":"/dump1", "httpMethod":"GET"}}
Stack Trace:
java.lang.AssertionError: Could not get expected value 'CY val' for path
'params/c' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"params":{
"a":"A val",
"b":"B val",
"wt":"json",
"useParams":""},
"context":{
"webapp":"",
"path":"/dump1",
"httpMethod":"GET"}}
at
__randomizedtesting.SeedInfo.seed([97FB533710C8B496:1FAF6CEDBE34D96E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:177)
at
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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
[jira] [Created] (SOLR-8919) Add SELECT COUNT(DISTINCT COL) queries to the SQL Interface
Joel Bernstein created SOLR-8919: Summary: Add SELECT COUNT(DISTINCT COL) queries to the SQL Interface Key: SOLR-8919 URL: https://issues.apache.org/jira/browse/SOLR-8919 Project: Solr Issue Type: Bug Reporter: Joel Bernstein While analyzing the Enron emails for SOLR-, I was wishing that COUNT(DISTINCT) was implemented. This ticket is to implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Priority: Major (was: Blocker) > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta > Fix For: master, 6.0, 5.5.1 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Fix Version/s: 5.5.1 > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta > Fix For: master, 6.0, 5.5.1 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217251#comment-15217251 ] Anshum Gupta commented on SOLR-8725: I really thought that the regex didn't work but the test I added seems to say otherwise! I'll skip the patch. I'll take a look at the 5.5.1 fix. Thanks for the patch. > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated LUCENE-7150:
Attachment: LUCENE-7150.patch
Second version of patch.
Can't hook up Robert's check because I don't know how to set up a cross-project
dependency in Lucene, but include commented out code for somebody else to
enable. Also, FWIW, the constructors in Geo3D all have range checks as well.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch, LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217154#comment-15217154
]
Karl Wright commented on LUCENE-7150:
-
Sure, we can do that. I'm sure it's doing the same thing I am: a single
multiplication.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217142#comment-15217142
]
Karl Wright commented on LUCENE-7150:
-
lucene.spatial is not apparently a dependency for lucene.spatial3d at this
time. Do you want me to add this?
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217140#comment-15217140
]
Michael McCandless commented on LUCENE-7150:
Whoa, with this patch, I'm getting close to the hit counts I see with the geo2d
impls (383M), even when using WGS84! Thank you [~daddywri]!
It's 383,371,877 with geo3d and 382,961,953 with geopoint, which is much closer
than I've ever seen.
Maybe we can share this constant for the earth?:
https://github.com/apache/lucene-solr/commit/9c98f9d95801fe6e64f7653667feb30ed80b9b8e#diff-ff4af375ef79ebff087ad91ce7778959R136
Can we just use {{Math.toRadians}}? Clearly I should not be trusted to write
my own {{toRadians}} ;)
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217128#comment-15217128
]
Robert Muir commented on LUCENE-7150:
-
Nice, thanks Karl!
Can we add GeoUtils.checkLatitude() and checkLongitude() to the public methods
taking lat/lon? They are helpful at detecting mistakes.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated LUCENE-7150:
Attachment: LUCENE-7150.patch
Initial patch. For Mike to test. More patches with more shape builders will
be included later.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8918) Add Streaming Expressions to the admin page
[ https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-8918: -- Attachment: sample-display.png Attaching a sample display (without search results) > Add Streaming Expressions to the admin page > --- > > Key: SOLR-8918 > URL: https://issues.apache.org/jira/browse/SOLR-8918 > Project: Solr > Issue Type: New Feature > Components: UI, web gui >Reporter: Dennis Gove > Attachments: SOLR-8918.patch, sample-display.png > > > Add to the admin page an ability to work with and view Streaming Expressions. > This tab will appear under the Collection selection section and will work > similarly to the Query tab. On this page the user will be able to enter a > streaming expression for execution. The user can then execute the expression > against the collection and view all the results as they are returned from the > Stream handler. Along with this the user will be able to view the structure > of the expression in a graph-like layout. > If the user wishes to only view the expression structure without executing > the expression the user will be able to click an "Explain" button which will > show the structure. Included in the structure will be information about each > node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8918) Add Streaming Expressions to the admin page
[ https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217084#comment-15217084 ] Dennis Gove edited comment on SOLR-8918 at 3/29/16 11:49 PM: - This patch adds a new section to work with Streaming Expressions. It is far from complete but I wanted to put it up to get people's feedback or ideas about the display. Executing an expression should show all the results. Explaining an expression is still under development but if you click that button it will show you the layout of a sample expression. Still requires work on the layout, canvas size, node display (I'm thinking different types of rectangles w/images for different types of Stream classes), and getting the expression explanation from the stream handler. was (Author: dpgove): This patch adds a new section to work with Streaming Expressions. It is far from complete but I wanted to put it up to get people's feedback or ideas about the display. Executing an expression should show all the results. Explaining an expression is still under development but if you click that button it will show you the layout of a sample expression. Still requires work on the layout, canvas size, node display (I'm thinking different types of rectangles w/images for different types of Stream classes). > Add Streaming Expressions to the admin page > --- > > Key: SOLR-8918 > URL: https://issues.apache.org/jira/browse/SOLR-8918 > Project: Solr > Issue Type: New Feature > Components: UI, web gui >Reporter: Dennis Gove > Attachments: SOLR-8918.patch > > > Add to the admin page an ability to work with and view Streaming Expressions. > This tab will appear under the Collection selection section and will work > similarly to the Query tab. On this page the user will be able to enter a > streaming expression for execution. The user can then execute the expression > against the collection and view all the results as they are returned from the > Stream handler. Along with this the user will be able to view the structure > of the expression in a graph-like layout. > If the user wishes to only view the expression structure without executing > the expression the user will be able to click an "Explain" button which will > show the structure. Included in the structure will be information about each > node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8918) Add Streaming Expressions to the admin page
[ https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-8918: -- Attachment: SOLR-8918.patch This patch adds a new section to work with Streaming Expressions. It is far from complete but I wanted to put it up to get people's feedback or ideas about the display. Executing an expression should show all the results. Explaining an expression is still under development but if you click that button it will show you the layout of a sample expression. Still requires work on the layout, canvas size, node display (I'm thinking different types of rectangles w/images for different types of Stream classes). > Add Streaming Expressions to the admin page > --- > > Key: SOLR-8918 > URL: https://issues.apache.org/jira/browse/SOLR-8918 > Project: Solr > Issue Type: New Feature > Components: UI, web gui >Reporter: Dennis Gove > Attachments: SOLR-8918.patch > > > Add to the admin page an ability to work with and view Streaming Expressions. > This tab will appear under the Collection selection section and will work > similarly to the Query tab. On this page the user will be able to enter a > streaming expression for execution. The user can then execute the expression > against the collection and view all the results as they are returned from the > Stream handler. Along with this the user will be able to view the structure > of the expression in a graph-like layout. > If the user wishes to only view the expression structure without executing > the expression the user will be able to click an "Explain" button which will > show the structure. Included in the structure will be information about each > node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8918) Add Streaming Expressions to the admin page
Dennis Gove created SOLR-8918: - Summary: Add Streaming Expressions to the admin page Key: SOLR-8918 URL: https://issues.apache.org/jira/browse/SOLR-8918 Project: Solr Issue Type: New Feature Components: UI, web gui Reporter: Dennis Gove Add to the admin page an ability to work with and view Streaming Expressions. This tab will appear under the Collection selection section and will work similarly to the Query tab. On this page the user will be able to enter a streaming expression for execution. The user can then execute the expression against the collection and view all the results as they are returned from the Stream handler. Along with this the user will be able to view the structure of the expression in a graph-like layout. If the user wishes to only view the expression structure without executing the expression the user will be able to click an "Explain" button which will show the structure. Included in the structure will be information about each node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217078#comment-15217078 ] Shawn Heisey commented on SOLR-8725: I think the regex did work before -- I tried a whole bunch of creation commands to see if I could break it and it seemed to work as advertised. The new one is easier to understand, but I believe it does the same task. My main concern was getting the fix backported to the 5.5 branch, so if we do release 5.5.1, it will have the fix. > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_72) - Build # 5744 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5744/ Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Captured an uncaught exception in thread: Thread[id=16639, name=SocketProxy-Response-64522:64850, state=RUNNABLE, group=TGRP-HttpPartitionTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=16639, name=SocketProxy-Response-64522:64850, state=RUNNABLE, group=TGRP-HttpPartitionTest] Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is closed at __randomizedtesting.SeedInfo.seed([7A2EE9637757120B]:0) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347) Caused by: java.net.SocketException: Socket is closed at java.net.Socket.setSoTimeout(Socket.java:1137) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344) Build Log: [...truncated 12057 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_7A2EE9637757120B-001\init-core-data-001 [junit4] 2> 2551521 INFO (SUITE-HttpPartitionTest-seed#[7A2EE9637757120B]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 2551529 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 2551529 INFO (Thread-6112) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 2551529 INFO (Thread-6112) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 2551630 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.ZkTestServer start zk server on port:64477 [junit4] 2> 2551630 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 2551631 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 2551634 INFO (zkCallback-2457-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@2662c477 name:ZooKeeperConnection Watcher:127.0.0.1:64477 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2551635 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 2551635 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 2551635 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 2551638 WARN (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] o.a.z.s.NIOServerCnxn caught end of stream exception [junit4] 2> EndOfStreamException: Unable to read additional data from client sessionid 0x153c4ab2be9, likely client has closed socket [junit4] 2>at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228) [junit4] 2>at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208) [junit4] 2>at java.lang.Thread.run(Thread.java:745) [junit4] 2> 2551640 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 2551641 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 2551643 INFO (zkCallback-2458-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@523b362 name:ZooKeeperConnection Watcher:127.0.0.1:64477/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2551643 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 2551643 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 2551643 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1 [junit4] 2> 2551645 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards [junit4] 2> 2551648 INFO (TEST-HttpPartitionTest.test-seed#[7A2EE9637757120B]) [] o.a.s.c.c.SolrZkClient makePath: /collections/control_collection [junit4] 2> 2551650 INFO
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Attachment: SOLR-8725-fix-regex.patch > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Attachment: (was: SOLR-8725-fix-regex.patch) > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reopened SOLR-8725: Shawn pointed out to an issue with the regular expression to me on irc. Here's a fix with a quick test. [~elyograg], mind taking a look? > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Priority: Blocker (was: Major) > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-8725: --- Attachment: SOLR-8725-fix-regex.patch > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta >Priority: Blocker > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725-fix-regex.patch, > SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217043#comment-15217043
]
Scott Blum commented on SOLR-8914:
--
Yeah, one of the things about ZK is it's impossible to view all changes as a
strict linear sequence using the client-facing watcher protocol, because the
watch events don't contain the data you want; by the time you can fetch the
data in response to the event, it's already stale, so you can absolutely miss
transient states. I assume that if you spoke ZK server replication protocol,
then you could get a linearized change sequence.
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8765) Enforce required parameters in SolrJ Collection APIs
[ https://issues.apache.org/jira/browse/SOLR-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217035#comment-15217035 ] Anshum Gupta commented on SOLR-8765: Do you want me to fix this? > Enforce required parameters in SolrJ Collection APIs > > > Key: SOLR-8765 > URL: https://issues.apache.org/jira/browse/SOLR-8765 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > Fix For: 6.1 > > Attachments: SOLR-8765-splitshard.patch, SOLR-8765-splitshard.patch, > SOLR-8765.patch, SOLR-8765.patch > > > Several Collection API commands have required parameters. We should make > these constructor parameters, to enforce setting these in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217036#comment-15217036
]
Scott Blum commented on SOLR-8914:
--
BTW, a million thanks to Hoss for digging into this. We've seen this in
production in certain circumstances, I think it's triggered when we have
multiple nodes experiencing long GC pauses at the same time, enough to drop ZK
sessions. The cluster can get into a state where it never fully recovers; but
we've found that if we perform a "live_nodes tickle" but dropping a dummy child
into "live_nodes" then deleting it, things fix themselves. I'm so thankful to
finally have an explanation, even if the root cause is my fault!
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217034#comment-15217034
]
Robert Muir commented on LUCENE-7150:
-
I think as a start haversin would be nice? It would at least allow us to do
some nice comparisons with the other geo impls. I too am curious about
performance of not just distance but also things like polygon queries.
Remember, we can always provide 'alternatives' at a later point or more
advanced apis. We can always add Geo3DAdvancedPoint in the future with wider
apis (e.g. taking planetmodel or using an ellipsoid model/vincenty/whatever),
or add additional methods. Its just as a start we need a sorta dumb-downed/very
simple lucene integration to start exploring the differences e.g. in query
performance and so on.
So I think we should steer in the direction of simplicity, make it brain dead
simple, and hard for someone to mess up (like us, trying to run benchmarks). We
have to start somewhere...
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217033#comment-15217033
]
Hoss Man commented on SOLR-8914:
{quote}
The part I don't understand is why this watcher is getting fired multiple times
on different threads. I (re)wrote some of this code, and one of my implicit
assumptions that was that any given watcher would not get re-fired until the
previous watcher invocation had returned. But maybe that was a really bad
assumption that I carried over from Curator, or perhaps the thread model in ZK
has changed?
{quote}
I have no idea what the thread model for ZK is, but let's assume your implicit
assumption was correct...
That would still match the observed behavior, and a hypothetical sequence of
events very similar to the one i outlined, since the
{{zkClient.getChildren(...)}} calls are passing the LiveNodeWatcher back to ZK.
so T1's call to {{zkClient.getChildren(...)}} call adds the LiveNodeWatcher
back, but before T1 has a chance to write it's local state that watcher fires
and triggers T2, and T2's {{zkClient.getChildren(...)}} call adds the
LiveNodeWatcher backm but before either T1 or T2 can write to the local state
that watcher fires and triggers T3, ... after T3 writes the local state, T1 and
T2 overwrite it with their stale data.
Your implicit assumption would alos explain the part i was confused about: why
there are only 4 {{live_nodes}} child events triggered instead of 5. 2 nodes
must have come online add added themselves to {{live_nodes/}} between the time
T2's watch even was triggered and when T2 added a new watcher via the
{{zkClient.getChildren(...)}} call (explaining the jump from "1" to "3")
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Blum updated SOLR-8914:
-
Attachment: SOLR-8914.patch
Here's a pretty simple patch that I believe should fix. I think #3 is probably
the safest option here.
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch,
> jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217011#comment-15217011
]
Scott Blum commented on SOLR-8914:
--
Hoss-- great analysis! I was just looking at this code myself. The part I
don't understand is why this watcher is getting fired multiple times on
different threads. I (re)wrote some of this code, and one of my implicit
assumptions that was that any given watcher would not get re-fired until the
previous watcher invocation had returned. But maybe that was a really bad
assumption that I carried over from Curator, or perhaps the thread model in ZK
has changed?
Either way, I completely agree that this is broken if we can get multiple
concurrent ZK callbacks on the same watcher.
getUpdateLock() is an overly broad lock, we should not try to hold that lock
while calling ZK.
I have a few proposals on how to fix:
1) Add a getChildren() variant that returns a Stat object, and use version
tracking. I could make an argument that this is the most sane way to break any
versioning ties, since it completely eliminates client-side concurrency issues
in the ZK framework code. If we don't do this, we're always implicitly
depending on our ability to linearly sequence getChildren calls.
2) Make the various Watcher objects lock themselves for the duration of
process(WatchedEvent event). That way, subsequent callbacks will have to
linearize.
3) Similar idea, but put that same set of locks as top-level fields in
ZkStateReader. This is like #2, but also protects against a multiple-watchers
scenario. I've tried to avoid situations of multiple watchers, there's no real
guard against multiple calls to createClusterStateWatchersAndUpdate().
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7149) Test2BPoints.test1D() failure
[
https://issues.apache.org/jira/browse/LUCENE-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-7149.
Resolution: Fixed
Fix Version/s: 6.0
> Test2BPoints.test1D() failure
> -
>
> Key: LUCENE-7149
> URL: https://issues.apache.org/jira/browse/LUCENE-7149
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Steve Rowe
> Fix For: 6.0
>
>
> My Jenkins found a failure on branch_6_0 - reproduces for me at commit
> 00ffee5:
> {noformat}
> Checking out Revision d610976261b473031cb70bcb95171379a99a5b3f
> (refs/remotes/origin/branch_6_0)
> [...]
>[junit4] HEARTBEAT J0 PID(11848@localhost): 2016-03-29T09:53:07, stalled
> for 4863s at: Test2BPoints.test1D
>[junit4] Suite: org.apache.lucene.index.Test2BPoints
>[junit4] 1> TEST: now CheckIndex
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=Test2BPoints
> -Dtests.method=test1D -Dtests.seed=A3E217F94A515C0 -Dtests.nightly=true
> -Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Dili
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 4881s J0 | Test2BPoints.test1D <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1250> but
> was:<0>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([A3E217F94A515C0:139DD275EC5198E4]:0)
>[junit4]> at
> org.apache.lucene.index.Test2BPoints.test1D(Test2BPoints.java:88)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-6.0-HDD/lucene/build/core/test/J0/temp/lucene.index.Test2BPoints_A3E217F94A515C0-001
>[junit4] 2> NOTE: test params are: codec=Lucene60,
> sim=ClassicSimilarity, locale=sv, timezone=Asia/Dili
>[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=627321624,total=2142240768
>[junit4] 2> NOTE: All tests run in this JVM: [TestIntsRef,
> TestIndexWriterForceMerge, TestSimpleFSLockFactory, TestDirectMonotonic,
> TestConjunctions, TestBooleanQuery, TestDocInverterPerFieldErrorInfo,
> TestSentinelIntSet, TestSegmentMerger, TestOmitNorms, TestSpanNearQuery,
> TestRoaringDocIdSet, TestTopDocsCollector, TestParallelLeafReader,
> TestDocumentsWriterDeleteQueue, TestTermVectorsReader,
> FiniteStringsIteratorTest, TestConcurrentMergeScheduler, TestPackedInts,
> TestReusableStringReader, TestBytesRef, TestToken,
> TestAllFilesHaveCodecHeader, TestDirectoryReaderReopen, TestAtomicUpdate,
> TestFastDecompressionMode, TestForUtil, TestSparseFixedBitSet,
> TestNeverDelete, TestCloseableThreadLocal, TestDoc, TestBytesRefArray,
> TestSpanFirstQuery, TestDeterminism, TestControlledRealTimeReopenThread,
> TestWeakIdentityMap, TestReaderWrapperDVTypeCheck,
> TestPositiveScoresOnlyCollector, TestExitableDirectoryReader,
> TestPerFieldPostingsFormat2, TestSearcherManager, TestPagedBytes,
> TestBooleanCoord, TestMultiCollector, TestIndexSearcher,
> TestFlushByRamOrCountsPolicy, TestExternalCodecs, TestShardSearching,
> TestIndexWriter, TestSortRescorer, TestSynonymQuery, TestFlex,
> TestLevenshteinAutomata, TestByteSlices, TestBufferedIndexInput,
> TestTermsEnum, TestSegmentReader, TestTransactions,
> TestMultiThreadTermVectors, TestFieldsReader, TestSimpleSearchEquivalence,
> TestCustomSearcherSort, TestTermsEnum2, TestLegacyNumericUtils,
> TestIndexWriterOnDiskFull, TestDocCount, TestCachingCollector,
> TestAutomatonQueryUnicode, TestAttributeSource, TestTotalHitCountCollector,
> TestRecyclingByteBlockAllocator, TestRamUsageEstimator, TestIsCurrent,
> TestNamedSPILoader, TestByteBlockPool, TestAssertions, TestCharFilter,
> TestRollback, TestTwoPhaseCommitTool, TestNot, TestIndexWriterOnJRECrash,
> Test4GBStoredFields, TestCodecHoldsOpenFiles, MultiCollectorTest,
> TestNGramPhraseQuery, TestSimpleAttributeImpl, TestIndexCommit, TestTerm,
> Test2BPostingsBytes, Test2BPagedBytes, TestBytesRefAttImpl,
> TestPackedTokenAttributeImpl, TestGrowableByteArrayDataOutput,
> TestBlockPostingsFormat, TestBlockPostingsFormat2,
> TestLucene50StoredFieldsFormat, TestLucene53NormsFormat,
> TestLucene54DocValuesFormat, TestLucene60PointsFormat, TestFieldType,
> Test2BPoints]
>[junit4] Completed [414/414 (1!)] on J0 in 116707.79s, 2 tests, 1 failure
> <<< FAILURES!
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7149) Test2BPoints.test1D() failure
[
https://issues.apache.org/jira/browse/LUCENE-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217008#comment-15217008
]
ASF subversion and git services commented on LUCENE-7149:
-
Commit 0db92bf6c2d9fa48bbce223407ba3b2c5956b463 in lucene-solr's branch
refs/heads/branch_6_0 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0db92bf ]
LUCENE-7149: fix wrong test assert
> Test2BPoints.test1D() failure
> -
>
> Key: LUCENE-7149
> URL: https://issues.apache.org/jira/browse/LUCENE-7149
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Steve Rowe
>
> My Jenkins found a failure on branch_6_0 - reproduces for me at commit
> 00ffee5:
> {noformat}
> Checking out Revision d610976261b473031cb70bcb95171379a99a5b3f
> (refs/remotes/origin/branch_6_0)
> [...]
>[junit4] HEARTBEAT J0 PID(11848@localhost): 2016-03-29T09:53:07, stalled
> for 4863s at: Test2BPoints.test1D
>[junit4] Suite: org.apache.lucene.index.Test2BPoints
>[junit4] 1> TEST: now CheckIndex
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=Test2BPoints
> -Dtests.method=test1D -Dtests.seed=A3E217F94A515C0 -Dtests.nightly=true
> -Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Dili
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 4881s J0 | Test2BPoints.test1D <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1250> but
> was:<0>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([A3E217F94A515C0:139DD275EC5198E4]:0)
>[junit4]> at
> org.apache.lucene.index.Test2BPoints.test1D(Test2BPoints.java:88)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-6.0-HDD/lucene/build/core/test/J0/temp/lucene.index.Test2BPoints_A3E217F94A515C0-001
>[junit4] 2> NOTE: test params are: codec=Lucene60,
> sim=ClassicSimilarity, locale=sv, timezone=Asia/Dili
>[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=627321624,total=2142240768
>[junit4] 2> NOTE: All tests run in this JVM: [TestIntsRef,
> TestIndexWriterForceMerge, TestSimpleFSLockFactory, TestDirectMonotonic,
> TestConjunctions, TestBooleanQuery, TestDocInverterPerFieldErrorInfo,
> TestSentinelIntSet, TestSegmentMerger, TestOmitNorms, TestSpanNearQuery,
> TestRoaringDocIdSet, TestTopDocsCollector, TestParallelLeafReader,
> TestDocumentsWriterDeleteQueue, TestTermVectorsReader,
> FiniteStringsIteratorTest, TestConcurrentMergeScheduler, TestPackedInts,
> TestReusableStringReader, TestBytesRef, TestToken,
> TestAllFilesHaveCodecHeader, TestDirectoryReaderReopen, TestAtomicUpdate,
> TestFastDecompressionMode, TestForUtil, TestSparseFixedBitSet,
> TestNeverDelete, TestCloseableThreadLocal, TestDoc, TestBytesRefArray,
> TestSpanFirstQuery, TestDeterminism, TestControlledRealTimeReopenThread,
> TestWeakIdentityMap, TestReaderWrapperDVTypeCheck,
> TestPositiveScoresOnlyCollector, TestExitableDirectoryReader,
> TestPerFieldPostingsFormat2, TestSearcherManager, TestPagedBytes,
> TestBooleanCoord, TestMultiCollector, TestIndexSearcher,
> TestFlushByRamOrCountsPolicy, TestExternalCodecs, TestShardSearching,
> TestIndexWriter, TestSortRescorer, TestSynonymQuery, TestFlex,
> TestLevenshteinAutomata, TestByteSlices, TestBufferedIndexInput,
> TestTermsEnum, TestSegmentReader, TestTransactions,
> TestMultiThreadTermVectors, TestFieldsReader, TestSimpleSearchEquivalence,
> TestCustomSearcherSort, TestTermsEnum2, TestLegacyNumericUtils,
> TestIndexWriterOnDiskFull, TestDocCount, TestCachingCollector,
> TestAutomatonQueryUnicode, TestAttributeSource, TestTotalHitCountCollector,
> TestRecyclingByteBlockAllocator, TestRamUsageEstimator, TestIsCurrent,
> TestNamedSPILoader, TestByteBlockPool, TestAssertions, TestCharFilter,
> TestRollback, TestTwoPhaseCommitTool, TestNot, TestIndexWriterOnJRECrash,
> Test4GBStoredFields, TestCodecHoldsOpenFiles, MultiCollectorTest,
> TestNGramPhraseQuery, TestSimpleAttributeImpl, TestIndexCommit, TestTerm,
> Test2BPostingsBytes, Test2BPagedBytes, TestBytesRefAttImpl,
> TestPackedTokenAttributeImpl, TestGrowableByteArrayDataOutput,
> TestBlockPostingsFormat, TestBlockPostingsFormat2,
> TestLucene50StoredFieldsFormat, TestLucene53NormsFormat,
> TestLucene54DocValuesFormat, TestLucene60PointsFormat, TestFieldType,
> Test2BPoints]
>[junit4] Completed [414/414 (1!)] on J0 in 116707.79s, 2 tests, 1 failure
> <<< FAILURES!
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail:
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216997#comment-15216997
]
Karl Wright commented on LUCENE-7150:
-
bq. pick something and be consistent
If I pick "haversine distance in meters" as being the input distance for this
API, is that consistent with the 2D api everywhere?
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216995#comment-15216995
]
Robert Muir commented on LUCENE-7150:
-
{quote}
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against.
{quote}
Its no a problem at all. For 1) pick something and be consistent. Its not
pluggable, its not optional, it does not need to be flexible here. For 2)
something dead simple like LatLonPoint.newPolygonQuery(String, double[],
double[]).
This *Point implementation we provide should be as simple and basic and natural
as possible. For anything else, someone can just make their own *Point class to
do something special.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216994#comment-15216994
]
Karl Wright commented on LUCENE-7150:
-
bq. If Mike cannot figure out how to do these things, I think nobody else
stands a chance.
I don't actually know what problem Mike is having. He claims that when he
halves the search radius he gets twice the points. I gave him extremely simple
code to try so I don't understand what is going on either. I'm going to
reserve judgement until we figure out what's actually happening.
I am a bit concerned that you folks may be (a) making a lot out of what is
probably a very simple bug, and (b) trying to oversimplify a rather complex
problem. I don't mind working hard to make API's as consistent as possible,
but there is a risk. Looking at distance measurements as a metaphor, there are
*lots* of ways to measure distance in an ellipsoidal world. And I don't know
if you've picked the best one.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216989#comment-15216989
]
Hoss Man commented on SOLR-8914:
bq. WTF?
our comments seem to have the same problem as refreshLiveNodes -- concurrent
updates. see the additional analysis i just posted
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216979#comment-15216979
]
Scott Blum commented on SOLR-8914:
--
This is super troubling
1290071 port 56361 Updated live nodes from ZooKeeper... (4) -> (5)
1290075 port 56361 Updated live nodes from ZooKeeper... (5) -> (1)
1290076 port 56361 Updated live nodes from ZooKeeper... (1) -> (3)
WTF?
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216980#comment-15216980
]
Karl Wright edited comment on LUCENE-7150 at 3/29/16 10:32 PM:
---
bq. What does Geo3D want instead?
It wants an angle. As I said, it currently uses radians for this. Conversion
from degrees is straightforward. Conversion from meters, on the other hand,
implies that you have to compute the inverse of the Vincenty distance (if you
want to do it accurately), or if your "distance" is in fact really the
spherical surface distance (what you guys are calling the "haversine
distance"), then it is a simple division.
bq. So it would be better to provide a Geo3DPoint class that has less
parameters (no PlanetModel), takes degrees (not radians), etc. It can
internally do any conversion that is needed to work with Geo3D.
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against. I proposed possibly
wrapping the shape factory methods too, but before that happens you will need
to inform me what measurements are meters and what are degrees. It really is
not obvious to me what the "obvious" choice is.
was (Author: kwri...@metacarta.com):
bq. What does Geo3D want instead?
It wants an angle. As I said, it currently uses radians for this. Conversion
from degrees is straightforward. Conversion from meters, on the other hand,
implies that you have to compute the inverse of the Vincenty distance (if you
want to do it accurately), or if your "distance" is in fact really the
spherical surface distance (what you guys are calling the "haversine distance",
then it is a simple division.
bq. So it would be better to provide a Geo3DPoint class that has less
parameters (no PlanetModel), takes degrees (not radians), etc. It can
internally do any conversion that is needed to work with Geo3D.
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against. I proposed possibly
wrapping the shape factory methods too, but before that happens you will need
to inform me what measurements are meters and what are degrees. It really is
not obvious to me what the "obvious" choice is.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216980#comment-15216980
]
Karl Wright commented on LUCENE-7150:
-
bq. What does Geo3D want instead?
It wants an angle. As I said, it currently uses radians for this. Conversion
from degrees is straightforward. Conversion from meters, on the other hand,
implies that you have to compute the inverse of the Vincenty distance (if you
want to do it accurately), or if your "distance" is in fact really the
spherical surface distance (what you guys are calling the "haversine distance",
then it is a simple division.
bq. So it would be better to provide a Geo3DPoint class that has less
parameters (no PlanetModel), takes degrees (not radians), etc. It can
internally do any conversion that is needed to work with Geo3D.
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against. I proposed possibly
wrapping the shape factory methods too, but before that happens you will need
to inform me what measurements are meters and what are degrees. It really is
not obvious to me what the "obvious" choice is.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8914:
---
Description:
Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
weekend
{noformat}
http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
(refs/remotes/origin/branch_6x)
Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
{noformat}
The failure happened during the static setup of the test, when a
MiniSolrCloudCluster & several clients are initialized -- before any code
related to TolerantUpdateProcessor is ever used.
I can't reproduce this, or really make sense of what i'm (not) seeing here in
the logs, so i'm filing this jira with my analysis in the hopes that someone
else can help make sense of it.
was:
Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
weekend
{noformat}
http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
(refs/remotes/origin/branch_6x)
Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
{noformat}
The failure happened during the static setup of the test, when a
MiniSolrCloudCluster & several clients are initialized -- before any code
related to TolerantUpdateProcessor is ever used.
I can't reproduce this, or really make sense of what i'm (not) seeing here in
the logs, so i'm filing this jira with my analysis in the hopes that someone
else can help make sense of it.
Summary: ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
(was: inexplicable "no servers hosting shard: shard2" using
MiniSolrCloudCluster)
Updating summary.
I suspect we either need to move the {{zkClient.getChildren(...)}} call inside
the existing {{synchronized (getUpdateLock())}} block, or the entire
{{refreshLiveNodes(Watcher watcher)}} method needs to synchronize on some new
"liveNodesLock".
> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
>
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt,
> live_node_mentions_port56361_with_threadIds.log.txt,
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a
> MiniSolrCloudCluster & several clients are initialized -- before any code
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in
> the logs, so i'm filing this jira with my analysis in the hopes that someone
> else can help make sense of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8914) inexplicable "no servers hosting shard: shard2" using MiniSolrCloudCluster
[
https://issues.apache.org/jira/browse/SOLR-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8914:
---
Attachment: live_node_mentions_port56361_with_threadIds.log.txt
Having read more of {{ZkStateReader}}, and understanding a bit better when/why
these various log messages are written, it now seems certain to me that
ZkStateReader's callbacks to watching {{live_nodes}} and updating that
information in the (local) {{ClusterState}} is *absolutely not thread safe*.
Key things to note about the ZkStateReader code related to live nodes and live
nodes log msgs...
* The following are examples of log message formats that occur when a ZK
{{Watcher}}'s process method is triggered - in all of these cases the # of live
nodes logged is the _current_ number, according to local state, prior to
processing the Watcher event...
** LegacyClusterStateWatcher (old multi-collections state.json)
*** {{"A cluster state change: \[\{\}\] for collection \[\{\}\] has occurred -
updating... (live nodes size: \[\{\}\])"}}
*** _NOTE: this is the current (local) {{liveNodes.size()}}, w/ no attempt to
refresh {{liveNodes}} from ZK_
** StateWatcher (per collection state.json)
*** {{"A cluster state change: \[\{\}\] for collection \[\{\}\] has occurred -
updating... (live nodes size: \[\{\}\])"}}
*** _NOTE: this is the current (local) {{liveNodes.size()}}, w/ no attempt to
refresh {{liveNodes}} from ZK_
** LiveNodeWatcher
*** {{"A live node change: \[\{\}\], has occurred - updating... (live nodes
size: \[\{\}\])"}}
*** *NOTE: This the "old" value when a LiveNodesWatcher is triggered, prior to
refreshing from ZK*
* The following is what gets logged _after_ the local cache of the live nodes
data has been updated (either by an explicit method call to fetch the data from
ZK on startup, or because a LiveNodeWatcher was triggered by ZK)
** {{"Updated live nodes from ZooKeeper... (\{\}) -> (\{\})"}}
* The full code for how the local cache of {{liveNode}} is refreshed from ZK
(either by an explifit method call on startup or because a LiveNodeWatcher was
triggered) is...{code}
try {
List nodeList = zkClient.getChildren(LIVE_NODES_ZKNODE, watcher,
true);
newLiveNodes = new HashSet<>(nodeList);
} catch (KeeperException.NoNodeException e) {
newLiveNodes = emptySet();
}
Set oldLiveNodes;
synchronized (getUpdateLock()) {
oldLiveNodes = this.liveNodes;
this.liveNodes = newLiveNodes;
if (clusterState != null) {
clusterState.setLiveNodes(newLiveNodes);
}
}
LOG.info("Updated live nodes from ZooKeeper... ({}) -> ({})",
oldLiveNodes.size(), newLiveNodes.size());
{code}
With all of that info in mind if we revisi the log file, and focus on the
threadIds that log each message for a single port we know is problematic
(56361)...
{code}
grep -i "live nodes" jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt |
grep 127.0.0.1:56361_solr | perl -ple 's/.*2>
(\d+).*?\((.*?-\d+)(?:-processing-n:127.*?)?\).*o.a.s.c.c.ZkStateReader(.*)/$1
$2 $3/' > live_node_mentions_port56361_with_threadIds.log.txt
{code}
...it becomes really easy to spot the problem...
{noformat}
1290004 jetty-launcher-1118-thread-5 Updated live nodes from ZooKeeper... (0)
-> (0)
1290033 zkCallback-1135-thread-1 A live node change: [WatchedEvent
state:SyncConnected type:NodeChildrenChanged path:/live_nodes], has occurred -
updating... (live nodes size: [0])
1290047 zkCallback-1135-thread-2 A live node change: [WatchedEvent
state:SyncConnected type:NodeChildrenChanged path:/live_nodes], has occurred -
updating... (live nodes size: [0])
1290052 zkCallback-1135-thread-3 A live node change: [WatchedEvent
state:SyncConnected type:NodeChildrenChanged path:/live_nodes], has occurred -
updating... (live nodes size: [0])
1290070 zkCallback-1135-thread-3 Updated live nodes from ZooKeeper... (0) ->
(4)
1290071 zkCallback-1135-thread-3 A live node change: [WatchedEvent
state:SyncConnected type:NodeChildrenChanged path:/live_nodes], has occurred -
updating... (live nodes size: [4])
1290071 zkCallback-1135-thread-3 Updated live nodes from ZooKeeper... (4) ->
(5)
1290075 zkCallback-1135-thread-1 Updated live nodes from ZooKeeper... (5) ->
(1)
1290076 zkCallback-1135-thread-2 Updated live nodes from ZooKeeper... (1) ->
(3)
{noformat}
* timestamp #1290004 is when jetty is first starting up, and forcibly asks ZK
for the list of live nodes.
* we then see 3 threads being spun up in numeric sequence order, to (start)
processing LiveNodeWatcher events
* thread-3 finishes and updates the live nodes to a list of size "4"
* thread-3 is then re-used to (start) processing another LiveNodeWatcher event
* thread-3 finishes again and updates the live nodes to a list of size "5"
* thread-1 now finally finishes, and overwrites the live node list with a list
of size "1" *even though it's data is almost certainly old*
* thread-1 now finally finishes, and also overwrites the
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216947#comment-15216947
]
Ryan Ernst commented on LUCENE-7150:
bq. It escapes me why degrees and distance in meters is a "natural"
measurement. To me, that's an arbitrary decision that somebody made (here).
It is the way humans have viewed distance and location for hundreds of years.
bq. If your notion of a geometric query is only all documents within circles
with a center then I challenge that – it's very very limiting and would not
handle polygons, paths, rectangles, or any of the other many variants of areas
somebody may well want to search within.
Of course I think users should be able to express queries (and indexed values!)
with these concepts. But for a user to have to use do the conversion themselves
from the standard units we describe locations on earth with into a spheroid
location is asking too much, they will never use it.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216944#comment-15216944
]
Robert Muir commented on LUCENE-7150:
-
{quote}
It escapes me why degrees and distance in meters is a "natural" measurement. To
me, that's an arbitrary decision that somebody made (here).
{quote}
Its not arbitrary. Look up your home town on wikipedia, the location is given
in latitude and longitude, not radians. This is just the way it is, its not any
decision that was made here, and its not arbitrary at all. It is just the way
the world works, that is what people have. :)
{quote}
The distance in meters as being the way you specify radii of circles is the
most problematic.
{quote}
Well, this is how people measure distance in this world! How else should i find
a pizza restaurant near my house? What units should i use if not meters? What
does Geo3D want instead?
{quote}
But I fully understand that Lucene has already decided what units it intends to
use and Geo3d in its current form is incompatible with that. And yet, "meters"
implies a surface distance and geo3d doesn't even have a concept of surface
distance. You could describe radii in degrees and that could match, but that's
not compatible with the 2D implementation.
So should I withdraw this contribution entirely? What is your suggestion?
{quote}
My suggestion is to do some "hiding" of the internal details. I think all mike
wanted to do was benchmark the distance query, to see how 3D compares against
2D.
So it would be better to provide a Geo3DPoint class that has less parameters
(no PlanetModel), takes degrees (not radians), etc. It can internally do any
conversion that is needed to work with Geo3D.
Nobody is arguing about what geo3d geometry apis should take. But can we fix
the API to be easy to use for a lucene user? If Mike cannot figure out how to
do these things, I think nobody else stands a chance.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216940#comment-15216940
]
Karl Wright commented on LUCENE-7150:
-
How do you understand that people would use geometric queries? If your notion
of a geometric query is only all documents within circles with a center then I
challenge that -- it's very very limiting and would not handle polygons, paths,
rectangles, or any of the other many variants of areas somebody may well want
to search within. If you agree that searching for those kinds of things is
important, then 99.% of the code that you view as useless becomes 10%
rather quickly, because that *is* what geo3d is about.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8875) ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in Overseer
[ https://issues.apache.org/jira/browse/SOLR-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-8875: - Attachment: SOLR-8875.patch I think this may be a one-liner; in the calling loop, I think there are cases where you can get all the way to the bottom without having actually written any updates, which fails to ever initialize ZkStateWriter.clusterState(). To be honest, I'm not a fan of both the Overseer loop and ZkStateWriter both trying to keep a source-of-truth clusterState variable, it's a recipe for getting out of sync. > ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in > Overseer > - > > Key: SOLR-8875 > URL: https://issues.apache.org/jira/browse/SOLR-8875 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: David Smiley > Attachments: SOLR-8875.patch > > > While trying to get the test in Varun's patch in SOLR-5750 (SolrCloud > collection backup & restore) to succeed, I kept hitting an NPE in Overseer in > which clusterState was null. I added a bunch of asserts and found where it > was happening which I worked around temporarily. See > https://github.com/apache/lucene-solr/commit/fd9c4d59e8dbe0e9fbd99a40ed2ff746c1ae7a0c#diff-9ed614eee66b9e685d73446b775dc043R247 > which is ZkStateWriter.writePendingUpdates() returning null, overwriting the > current non-null clusterState. This happens nearly every time for me when I > run that test. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216924#comment-15216924
]
Karl Wright commented on LUCENE-7150:
-
It escapes me why degrees and distance in meters is a "natural" measurement.
To me, that's an arbitrary decision that somebody made (here). The distance in
meters as being the way you specify radii of circles is the most problematic.
But I fully understand that Lucene has already decided what units it intends to
use and Geo3d in its current form is incompatible with that. And yet, "meters"
implies a surface distance and geo3d doesn't even have a concept of surface
distance. You could describe radii in degrees and that could match, but that's
not compatible with the 2D implementation.
So should I withdraw this contribution entirely? What is your suggestion?
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216918#comment-15216918
]
Ryan Ernst commented on LUCENE-7150:
bq. One problem at the moment is that all of geo3d works against a unit
sphere/ellipsoid, and uses units of radians.
bq. But this is an implementation detail. Literally, no user cares about this.
I agree this should be an implementation detail. Having all of these "solids"
and stuff as part of the public api just means 0.1% will ever use this, and
that is a lot of code to keep around for such an esoteric use case. Advanced
users like that can still use eg PointsFormat to index in multiple dimensions
as their use case necessitates, but "geo" functionality should really be simple
for 99.% of users. I'm happy that we have geo3d here, but I think the name
still needs to be clearer (this is *not* 3d that almost any user would ever
think about) and we need public apis (and those to be the *only* public apis)
that operate the exact same as the other sphere based lat/lon geo support we
have (as the issue title implies).
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216902#comment-15216902
]
Robert Muir commented on LUCENE-7150:
-
{quote}
One problem at the moment is that all of geo3d works against a unit
sphere/ellipsoid, and uses units of radians.
{quote}
But this is an implementation detail. Literally, no user cares about this.
The api should be simple: it should take common stuff that users have like
latitude, longitude, distance in meters. A user could care less what is
happening behind the scenes!
It does not matter about esoteric use cases, it does not matter if this geo3d
can be used to model the earth the shape of an apple or to compute distance on
jupiter’s rings.
We should provide one field: one that works on planet earth, takes
lat,lon,meters, stuff like that. Anything else can be a custom query.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216884#comment-15216884
]
Karl Wright commented on LUCENE-7150:
-
Another interesting question this begs is what exactly *is* the public API of
geo3d?
I would claim it consists of the following:
- Construction of shapes
- Construction of points
- Evaluating intersection/overlap/etc between shapes (GeoShape interface)
- Evaluating relationship between shapes and points (Membership interface)
- Computing "inside" distances (as represented by the GeoDistance interface)
- Computing "outside" distances (as represented by GeoOutsideDistance interface)
[~mikemccand], would you agree?
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 41 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/41/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.handler.TestReqParamsAPI.test
Error Message:
Could not get expected value 'null' for path 'response/params/y/p' full
output: { "responseHeader":{ "status":0, "QTime":0}, "response":{
"znodeVersion":4, "params":{ "x":{ "a":"A val",
"b":"B val", "_appends_":{"add":"first"},
"_invariants_":{"fixed":"f"}, "":{"v":1}}, "y":{ "p":"P
val", "q":"Q val", "":{"v":2}
Stack Trace:
java.lang.AssertionError: Could not get expected value 'null' for path
'response/params/y/p' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"response":{
"znodeVersion":4,
"params":{
"x":{
"a":"A val",
"b":"B val",
"_appends_":{"add":"first"},
"_invariants_":{"fixed":"f"},
"":{"v":1}},
"y":{
"p":"P val",
"q":"Q val",
"":{"v":2}
at
__randomizedtesting.SeedInfo.seed([E226DD9A39E9295A:6A72E240971544A2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:264)
at
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
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:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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
[jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216842#comment-15216842
]
Karl Wright commented on LUCENE-7150:
-
One problem at the moment is that all of geo3d works against a unit
sphere/ellipsoid, and uses units of radians. The Geo3DPoint does the same.
Argument compatibility would require that this be changed to degrees and
meters, and a common measure of earth radius be introduced.
Converting *everything* to degrees and meters is both unnecessary and unwise,
in my opinion. It introduces constants all over the place that really don't
add anything logically or numerically. But there are a number of shapes that
one creates now using radians, e.g polygons, circles, xyz solids, rectangles,
etc. Some of these use a builder-type metaphor which means multiple method
invocations are needed to construct the object.
So maybe it's possible, but non-trivial, to construct a wrapper around geo3d
for constructing objects? Seems like a lot of work for not much gain.
> geo3d public APIs should match the 2D apis?
> ---
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7150) geo3d public APIs should match the 2D apis?
Michael McCandless created LUCENE-7150:
--
Summary: geo3d public APIs should match the 2D apis?
Key: LUCENE-7150
URL: https://issues.apache.org/jira/browse/LUCENE-7150
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
I'm struggling to benchmark the equivalent to {{LatLonPoint.newDistanceQuery}}
in the geo3d world.
Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
take degrees, not radians, and radiusMeters, not an angle?
And if I index and search using {{PlanetModel.SPHERE}} I think it should
ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Move to non deprecated HttpClient impl classes to remove stale connection check on every request and move connection lifecycle management towards the client.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4509: -- Attachment: 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch Okay, here is pretty reasonable patch I think. I will start reviewing all these changes. > Move to non deprecated HttpClient impl classes to remove stale connection > check on every request and move connection lifecycle management towards the > client. > - > > Key: SOLR-4509 > URL: https://issues.apache.org/jira/browse/SOLR-4509 > Project: Solr > Issue Type: Improvement > Components: search > Environment: 5 node SmartOS cluster (all nodes living in same global > zone - i.e. same physical machine) >Reporter: Ryan Zezeski >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, master > > Attachments: > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > 0001-SOLR-4509-Move-to-non-deprecated-HttpClient-impl-cla.patch, > IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, > baremetal-stale-nostale-med-latency.dat, > baremetal-stale-nostale-med-latency.svg, > baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg > > > By disabling the Apache HTTP Client stale check I've witnessed a 2-4x > increase in throughput and reduction of over 100ms. This patch was made in > the context of a project I'm leading, called Yokozuna, which relies on > distributed search. > Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 > Here's a write-up I did on my findings: > http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html > I'm happy to answer any questions or make changes to the patch to make it > acceptable. > ReviewBoard: https://reviews.apache.org/r/28393/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Ernst resolved LUCENE-7147. Resolution: Fixed Assignee: Ryan Ernst Fix Version/s: 6.1 master > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst >Assignee: Ryan Ernst > Fix For: master, 6.1 > > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Attachment: SOLR-.patch
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch, SOLR-.patch, SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8899) MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close
[ https://issues.apache.org/jira/browse/SOLR-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216783#comment-15216783 ] Mark Miller commented on SOLR-8899: --- Yeah, practically these things don't tend to matter, but we really want to clean up for tests that run in the same JVM, and it lets us add automation to ensure new code cleans up without adding annotation exceptions. SOLR-4509 moves to an HttpClient impl that starts threads, and it was already a good idea to shutdown the connection pool. > MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does > not close > - > > Key: SOLR-8899 > URL: https://issues.apache.org/jira/browse/SOLR-8899 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8899) MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close
[ https://issues.apache.org/jira/browse/SOLR-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216776#comment-15216776 ] Joel Bernstein commented on SOLR-8899: -- The IterativeMergeStrategy has a static HttpClient, which was designed to be cached and used for all calls. it's not shutdown at all even when Solr is shutdown. I'll change that so it's shutdown and recreated after each use. > MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does > not close > - > > Key: SOLR-8899 > URL: https://issues.apache.org/jira/browse/SOLR-8899 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 487 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/487/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ObjectTracker found 4 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([54EB7CD0CE80B83D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) 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:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=16643, name=searcherExecutor-7334-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=16643, name=searcherExecutor-7334-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at
[jira] [Commented] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216724#comment-15216724 ] ASF subversion and git services commented on LUCENE-7147: - Commit 0cf26bf368f9e08346df80f025ad021d5b3dbfe1 in lucene-solr's branch refs/heads/branch_6x from [~rjernst] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0cf26bf ] LUCENE-7147: Improve disjoint check for geo distance query traversal > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16375 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16375/ Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.test Error Message: There should be one document because overwrite=true expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: There should be one document because overwrite=true expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([1C2A27AFEC4AB856:947E187542B6D5AE]: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.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:156) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:120) 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:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) 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
[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name
[ https://issues.apache.org/jira/browse/SOLR-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-8725: --- Attachment: SOLR-8725-5_5.patch I could not cherry-pick this change to the 5.5 branch, or even apply it as a patch. The later branches have deviated too far. Instead I hand-edited a minimally invasive change to the pattern, the javadoc, and the message in the thrown exception. Patch for branch_5_5 attached. If I temporarily revert an ill-advised commit that I made to change the version to 5.5.1, precommit passes. > Cores, collections, and shards should accept hyphens in identifier name > --- > > Key: SOLR-8725 > URL: https://issues.apache.org/jira/browse/SOLR-8725 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Chris Beer >Assignee: Anshum Gupta > Fix For: master, 6.0 > > Attachments: SOLR-8725-5_5.patch, SOLR-8725.patch, SOLR-8725.patch > > > In SOLR-8642, hyphens are no longer considered valid identifiers for cores > (and collections?). Our solr instance was successfully using hyphens in our > core names, and our affected cores now error with: > marc-profiler_shard1_replica1: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist > entirely of periods, underscores and alphanumerics > Before starting to rename all of our collections, I wonder if this decision > could be revisited to be backwards compatible with previously created > collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7149) Test2BPoints.test1D() failure
[
https://issues.apache.org/jira/browse/LUCENE-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216686#comment-15216686
]
Michael McCandless commented on LUCENE-7149:
Whoa, thanks [~steve_rowe] ... I think this is a test bug that was already
fixed in 6.x but I failed to backport for 6.0. I'll fix!
> Test2BPoints.test1D() failure
> -
>
> Key: LUCENE-7149
> URL: https://issues.apache.org/jira/browse/LUCENE-7149
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Steve Rowe
>
> My Jenkins found a failure on branch_6_0 - reproduces for me at commit
> 00ffee5:
> {noformat}
> Checking out Revision d610976261b473031cb70bcb95171379a99a5b3f
> (refs/remotes/origin/branch_6_0)
> [...]
>[junit4] HEARTBEAT J0 PID(11848@localhost): 2016-03-29T09:53:07, stalled
> for 4863s at: Test2BPoints.test1D
>[junit4] Suite: org.apache.lucene.index.Test2BPoints
>[junit4] 1> TEST: now CheckIndex
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=Test2BPoints
> -Dtests.method=test1D -Dtests.seed=A3E217F94A515C0 -Dtests.nightly=true
> -Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Dili
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 4881s J0 | Test2BPoints.test1D <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1250> but
> was:<0>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([A3E217F94A515C0:139DD275EC5198E4]:0)
>[junit4]> at
> org.apache.lucene.index.Test2BPoints.test1D(Test2BPoints.java:88)
>[junit4]> at java.lang.Thread.run(Thread.java:745)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-6.0-HDD/lucene/build/core/test/J0/temp/lucene.index.Test2BPoints_A3E217F94A515C0-001
>[junit4] 2> NOTE: test params are: codec=Lucene60,
> sim=ClassicSimilarity, locale=sv, timezone=Asia/Dili
>[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=627321624,total=2142240768
>[junit4] 2> NOTE: All tests run in this JVM: [TestIntsRef,
> TestIndexWriterForceMerge, TestSimpleFSLockFactory, TestDirectMonotonic,
> TestConjunctions, TestBooleanQuery, TestDocInverterPerFieldErrorInfo,
> TestSentinelIntSet, TestSegmentMerger, TestOmitNorms, TestSpanNearQuery,
> TestRoaringDocIdSet, TestTopDocsCollector, TestParallelLeafReader,
> TestDocumentsWriterDeleteQueue, TestTermVectorsReader,
> FiniteStringsIteratorTest, TestConcurrentMergeScheduler, TestPackedInts,
> TestReusableStringReader, TestBytesRef, TestToken,
> TestAllFilesHaveCodecHeader, TestDirectoryReaderReopen, TestAtomicUpdate,
> TestFastDecompressionMode, TestForUtil, TestSparseFixedBitSet,
> TestNeverDelete, TestCloseableThreadLocal, TestDoc, TestBytesRefArray,
> TestSpanFirstQuery, TestDeterminism, TestControlledRealTimeReopenThread,
> TestWeakIdentityMap, TestReaderWrapperDVTypeCheck,
> TestPositiveScoresOnlyCollector, TestExitableDirectoryReader,
> TestPerFieldPostingsFormat2, TestSearcherManager, TestPagedBytes,
> TestBooleanCoord, TestMultiCollector, TestIndexSearcher,
> TestFlushByRamOrCountsPolicy, TestExternalCodecs, TestShardSearching,
> TestIndexWriter, TestSortRescorer, TestSynonymQuery, TestFlex,
> TestLevenshteinAutomata, TestByteSlices, TestBufferedIndexInput,
> TestTermsEnum, TestSegmentReader, TestTransactions,
> TestMultiThreadTermVectors, TestFieldsReader, TestSimpleSearchEquivalence,
> TestCustomSearcherSort, TestTermsEnum2, TestLegacyNumericUtils,
> TestIndexWriterOnDiskFull, TestDocCount, TestCachingCollector,
> TestAutomatonQueryUnicode, TestAttributeSource, TestTotalHitCountCollector,
> TestRecyclingByteBlockAllocator, TestRamUsageEstimator, TestIsCurrent,
> TestNamedSPILoader, TestByteBlockPool, TestAssertions, TestCharFilter,
> TestRollback, TestTwoPhaseCommitTool, TestNot, TestIndexWriterOnJRECrash,
> Test4GBStoredFields, TestCodecHoldsOpenFiles, MultiCollectorTest,
> TestNGramPhraseQuery, TestSimpleAttributeImpl, TestIndexCommit, TestTerm,
> Test2BPostingsBytes, Test2BPagedBytes, TestBytesRefAttImpl,
> TestPackedTokenAttributeImpl, TestGrowableByteArrayDataOutput,
> TestBlockPostingsFormat, TestBlockPostingsFormat2,
> TestLucene50StoredFieldsFormat, TestLucene53NormsFormat,
> TestLucene54DocValuesFormat, TestLucene60PointsFormat, TestFieldType,
> Test2BPoints]
>[junit4] Completed [414/414 (1!)] on J0 in 116707.79s, 2 tests, 1 failure
> <<< FAILURES!
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216680#comment-15216680 ] ASF subversion and git services commented on LUCENE-7147: - Commit 045659533cdbcc7c57a38cd2aa0278312011da43 in lucene-solr's branch refs/heads/master from [~rjernst] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0456595 ] LUCENE-7147: Improve disjoint check for geo distance query traversal > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216649#comment-15216649
]
Joel Bernstein edited comment on SOLR- at 3/29/16 7:04 PM:
---
I think this almost ready to commit. As [~dpgove] points out it's not a generic
solution for graph traversals, but it's a useful recipe that probably deserves
a top level expression. As more generic approaches are developed we can always
swap out the implementation to use generic solutions.
The next step I believe would be to implement a nodes() expression, which would
use the same parallel joining technique used in this ticket. But instead of
finding the shortest path it will simply iterate the nodes and track the
traversal. This could be wrapped by other streams to operate over.
The nodes() expression will also be needed to support Tinkerpop/Gremlin, which
is an important goal as well.
was (Author: joel.bernstein):
I think this almost ready to commit. As [~dpgove] points out it's not a generic
solution for graph traversals, but it's a useful recipe that probably deserves
a top level expression. As more generic approaches are developed we can always
swap out the implementation to use generic solutions.
The next step I believe would be to implement a nodes() expression, which would
use the same parallel joining technique used in this ticket. But instead of
finding the shortest path it will simply iterate the nodes and track the
traversal. This could be wrapped by other streams to operate over.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch, SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216649#comment-15216649
]
Joel Bernstein commented on SOLR-:
--
I think this almost ready to commit. As [~dpgove] points out it's not a generic
solution for graph traversals, but it's a useful recipe that probably deserves
a top level expression. As more generic approaches are developed we can always
swap out the implementation to use generic solutions.
The next step I believe would be to implement a nodes() expression, which would
use the same parallel joining technique used in this ticket. But instead of
finding the shortest path it will simply iterate the nodes and track the
traversal. This could be wrapped by other streams to operate over.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch, SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216613#comment-15216613 ] Michael McCandless commented on LUCENE-7147: Those are great examples [~rjernst], thanks! I put them here: http://home.apache.org/~mikemccand/example-crosses-axis-not-center.html http://home.apache.org/~mikemccand/example-intersects-bbox-not-circle.html > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216584#comment-15216584
]
Joel Bernstein edited comment on SOLR- at 3/29/16 6:33 PM:
---
Patch with the StreamExpression methods implemented and Stream Exrpression test
cases
was (Author: joel.bernstein):
Patch the StreamExpression methods implemented and Stream Exrpression test cases
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch, SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Attachment: SOLR-.patch
Patch the StreamExpression methods implemented and Stream Exrpression test cases
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch, SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216218#comment-15216218 ] Ryan Ernst edited comment on LUCENE-7147 at 3/29/16 6:05 PM: - I've attached 2 examples. They both use the same geo distance query. Imagine someone from London says "I want to find places to travel within 1170km". So they do a distance search. The [first example|^example-intersects-bbox-not-circle.html] shows how this would require us to compute the distances from london to all the points indexes in the box covering Italy. The [second example|^example-crosses-axis-not-center.html] shows how if we were to use the naive approach of using the latitude of the circle center, we would incorrectly exclude a chunk of Poland thinking it did not intersect the circle because all corners are outside the circle, and it lies completely above the circle center latitude, but in fact it crosses the axis of the bbox. was (Author: rjernst): I've attached 2 examples.They both use the same geo distance query. Imagine someone from London says "I want to find places to travel within 1143km". So they do a distance search. The "intersects bbox not circle" example shows how this would require us to compute the distances from london to all the points indexes in the box covering Italy. The second example shows how if we were to use the naive approach of using the latitude of the circle center, we would incorrectly exclude a chunk of Poland thinking it did not intersect the circle because all corners are outside the circle, and it lies completely above the circle center latitude, but in fact it crosses the axis of the bbox. > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Ernst updated LUCENE-7147: --- Attachment: (was: example-crosses-axis-not-center.html) > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Ernst updated LUCENE-7147: --- Attachment: example-crosses-axis-not-center.html > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?
[ https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216499#comment-15216499 ] Shawn Heisey commented on SOLR-8110: bq. Is it possible to enable support for dashes with a JVM arg (or something else)? No. Only the patch for SOLR-8725 can make it work. I'm going to look into patching the 5.5 branch so it will be in 5.5.1 if that version is ever released. > Start enforcing field naming recomendations in next X.0 release? > > > Key: SOLR-8110 > URL: https://issues.apache.org/jira/browse/SOLR-8110 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > Attachments: SOLR-8110.patch, SOLR-8110.patch > > > For a very long time now, Solr has made the following "recommendation" > regarding field naming conventions... > bq. field names should consist of alphanumeric or underscore characters only > and not start with a digit. This is not currently strictly enforced, but > other field names will not have first class support from all components and > back compatibility is not guaranteed. ... > I'm opening this issue to track discussion about if/how we should start > enforcing this as a rule instead (instead of just a "recommendation") in our > next/future X.0 (ie: major) release. > The goals of doing so being: > * simplify some existing code/apis that currently use hueristics to deal with > lists of field and produce strange errors when the huerstic fails (example: > ReturnFields.add) > * reduce confusion/pain for new users who might start out unaware of the > recommended conventions and then only later encountering a situation where > their field names are not supported by some feature and get frustrated > because they have to change their schema, reindex, update index/query client > expectations, etc... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_72) - Build # 290 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/290/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler
Error Message:
ObjectTracker found 2 object(s) that were not released!!! [NRTCachingDirectory,
NRTCachingDirectory]
Stack Trace:
java.lang.AssertionError: ObjectTracker found 2 object(s) that were not
released!!! [NRTCachingDirectory, NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([87977D1AFDF5CA7A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)
Build Log:
[...truncated 11559 lines...]
[junit4] Suite: org.apache.solr.handler.TestReplicationHandler
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestReplicationHandler_87977D1AFDF5CA7A-001/init-core-data-001
[junit4] 2> 960303 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.a.s.SolrTestCaseJ4 ###Starting doTestRepeater
[junit4] 2> 960303 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.a.s.SolrTestCaseJ4 Writing core.properties file to
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestReplicationHandler_87977D1AFDF5CA7A-001/solr-instance-001/collection1
[junit4] 2> 960306 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 960307 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@359627e2{/solr,null,AVAILABLE}
[junit4] 2> 960312 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.e.j.s.ServerConnector Started
ServerConnector@752e5455{HTTP/1.1,[http/1.1]}{127.0.0.1:46780}
[junit4] 2> 960312 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.e.j.s.Server Started @962326ms
[junit4] 2> 960312 INFO
(TEST-TestReplicationHandler.doTestRepeater-seed#[87977D1AFDF5CA7A]) []
o.a.s.c.s.e.JettySolrRunner Jetty properties:
{solr.data.dir=/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestReplicationHandler_87977D1AFDF5CA7A-001/solr-instance-001/collection1/data,
hostContext=/solr, hostPort=46780}
[junit4] 2> 960312 INFO
[jira] [Updated] (SOLR-8899) MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close
[ https://issues.apache.org/jira/browse/SOLR-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-8899: -- Summary: MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close (was: MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close.) > MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does > not close > - > > Key: SOLR-8899 > URL: https://issues.apache.org/jira/browse/SOLR-8899 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7149) Test2BPoints.test1D() failure
Steve Rowe created LUCENE-7149:
--
Summary: Test2BPoints.test1D() failure
Key: LUCENE-7149
URL: https://issues.apache.org/jira/browse/LUCENE-7149
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 6.0
Reporter: Steve Rowe
My Jenkins found a failure on branch_6_0 - reproduces for me at commit 00ffee5:
{noformat}
Checking out Revision d610976261b473031cb70bcb95171379a99a5b3f
(refs/remotes/origin/branch_6_0)
[...]
[junit4] HEARTBEAT J0 PID(11848@localhost): 2016-03-29T09:53:07, stalled for
4863s at: Test2BPoints.test1D
[junit4] Suite: org.apache.lucene.index.Test2BPoints
[junit4] 1> TEST: now CheckIndex
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=Test2BPoints
-Dtests.method=test1D -Dtests.seed=A3E217F94A515C0 -Dtests.nightly=true
-Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Dili
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 4881s J0 | Test2BPoints.test1D <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1250> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([A3E217F94A515C0:139DD275EC5198E4]:0)
[junit4]>at
org.apache.lucene.index.Test2BPoints.test1D(Test2BPoints.java:88)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: leaving temporary files on disk at:
/slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-6.0-HDD/lucene/build/core/test/J0/temp/lucene.index.Test2BPoints_A3E217F94A515C0-001
[junit4] 2> NOTE: test params are: codec=Lucene60, sim=ClassicSimilarity,
locale=sv, timezone=Asia/Dili
[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=627321624,total=2142240768
[junit4] 2> NOTE: All tests run in this JVM: [TestIntsRef,
TestIndexWriterForceMerge, TestSimpleFSLockFactory, TestDirectMonotonic,
TestConjunctions, TestBooleanQuery, TestDocInverterPerFieldErrorInfo,
TestSentinelIntSet, TestSegmentMerger, TestOmitNorms, TestSpanNearQuery,
TestRoaringDocIdSet, TestTopDocsCollector, TestParallelLeafReader,
TestDocumentsWriterDeleteQueue, TestTermVectorsReader,
FiniteStringsIteratorTest, TestConcurrentMergeScheduler, TestPackedInts,
TestReusableStringReader, TestBytesRef, TestToken, TestAllFilesHaveCodecHeader,
TestDirectoryReaderReopen, TestAtomicUpdate, TestFastDecompressionMode,
TestForUtil, TestSparseFixedBitSet, TestNeverDelete, TestCloseableThreadLocal,
TestDoc, TestBytesRefArray, TestSpanFirstQuery, TestDeterminism,
TestControlledRealTimeReopenThread, TestWeakIdentityMap,
TestReaderWrapperDVTypeCheck, TestPositiveScoresOnlyCollector,
TestExitableDirectoryReader, TestPerFieldPostingsFormat2, TestSearcherManager,
TestPagedBytes, TestBooleanCoord, TestMultiCollector, TestIndexSearcher,
TestFlushByRamOrCountsPolicy, TestExternalCodecs, TestShardSearching,
TestIndexWriter, TestSortRescorer, TestSynonymQuery, TestFlex,
TestLevenshteinAutomata, TestByteSlices, TestBufferedIndexInput, TestTermsEnum,
TestSegmentReader, TestTransactions, TestMultiThreadTermVectors,
TestFieldsReader, TestSimpleSearchEquivalence, TestCustomSearcherSort,
TestTermsEnum2, TestLegacyNumericUtils, TestIndexWriterOnDiskFull,
TestDocCount, TestCachingCollector, TestAutomatonQueryUnicode,
TestAttributeSource, TestTotalHitCountCollector,
TestRecyclingByteBlockAllocator, TestRamUsageEstimator, TestIsCurrent,
TestNamedSPILoader, TestByteBlockPool, TestAssertions, TestCharFilter,
TestRollback, TestTwoPhaseCommitTool, TestNot, TestIndexWriterOnJRECrash,
Test4GBStoredFields, TestCodecHoldsOpenFiles, MultiCollectorTest,
TestNGramPhraseQuery, TestSimpleAttributeImpl, TestIndexCommit, TestTerm,
Test2BPostingsBytes, Test2BPagedBytes, TestBytesRefAttImpl,
TestPackedTokenAttributeImpl, TestGrowableByteArrayDataOutput,
TestBlockPostingsFormat, TestBlockPostingsFormat2,
TestLucene50StoredFieldsFormat, TestLucene53NormsFormat,
TestLucene54DocValuesFormat, TestLucene60PointsFormat, TestFieldType,
Test2BPoints]
[junit4] Completed [414/414 (1!)] on J0 in 116707.79s, 2 tests, 1 failure
<<< FAILURES!
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8875) ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in Overseer
[ https://issues.apache.org/jira/browse/SOLR-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216253#comment-15216253 ] Scott Blum commented on SOLR-8875: -- Perfect! Thank you > ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in > Overseer > - > > Key: SOLR-8875 > URL: https://issues.apache.org/jira/browse/SOLR-8875 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: David Smiley > > While trying to get the test in Varun's patch in SOLR-5750 (SolrCloud > collection backup & restore) to succeed, I kept hitting an NPE in Overseer in > which clusterState was null. I added a bunch of asserts and found where it > was happening which I worked around temporarily. See > https://github.com/apache/lucene-solr/commit/fd9c4d59e8dbe0e9fbd99a40ed2ff746c1ae7a0c#diff-9ed614eee66b9e685d73446b775dc043R247 > which is ZkStateWriter.writePendingUpdates() returning null, overwriting the > current non-null clusterState. This happens nearly every time for me when I > run that test. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6566) Handle "crosses dateline" cases in BKPointInPolygonQuery
[ https://issues.apache.org/jira/browse/LUCENE-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6566. Resolution: Won't Fix +1 to disallow "crosses dateline" polygons! > Handle "crosses dateline" cases in BKPointInPolygonQuery > > > Key: LUCENE-6566 > URL: https://issues.apache.org/jira/browse/LUCENE-6566 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: master, 6.1 > > > Just like LUCENE-6560, but we should also handle for the polygon case, which > seems harder ... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7147) Improve disjoint check for geo distance query traversal
[ https://issues.apache.org/jira/browse/LUCENE-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Ernst updated LUCENE-7147: --- Attachment: example-intersects-bbox-not-circle.html example-crosses-axis-not-center.html I've attached 2 examples.They both use the same geo distance query. Imagine someone from London says "I want to find places to travel within 1143km". So they do a distance search. The "intersects bbox not circle" example shows how this would require us to compute the distances from london to all the points indexes in the box covering Italy. The second example shows how if we were to use the naive approach of using the latitude of the circle center, we would incorrectly exclude a chunk of Poland thinking it did not intersect the circle because all corners are outside the circle, and it lies completely above the circle center latitude, but in fact it crosses the axis of the bbox. > Improve disjoint check for geo distance query traversal > --- > > Key: LUCENE-7147 > URL: https://issues.apache.org/jira/browse/LUCENE-7147 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ryan Ernst > Attachments: LUCENE-7147.patch, example-crosses-axis-not-center.html, > example-intersects-bbox-not-circle.html > > > When doing geo distance queries, it is important to avoid traversing subtrees > which do not contain any relevant points. We currently have checks which > compare the bbox of the query to the bounds of the subtree. However, it is > possible for a subtree to overlap the bbox, but still not intersect the > query. This issue is to improve that check to avoid unnecessary traversals. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="j...@company.com",
to="j...@company.com",
edge="from=to",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search starts from the node
j...@company.com and searches for the node j...@company.com, traversing the
*edges* by iteratively joining the *from* and *to* columns. Each level in the
traversal is implemented as a *parallel partitioned* nested loop join across
the entire *collection*. The *threads* parameter controls the number of threads
performing the join at each level. The *partitionSize* controls the of number
of nodes in each join partition. *maxDepth* controls the number of levels to
traverse. *fq* is a limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="j...@company.com",
to="j...@company.com",
edge="from=to",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search starts from the node
j...@company.com and searches for the node j...@company.com, traversing the
*edge* by iteratively joining the *from* and *to* columns. Each level in the
traversal is implemented as a *parallel partitioned* nested loop join across
the entire *collection*. The *threads* parameter controls the number of threads
performing the join at each level. The *partitionSize* controls the of number
of nodes in each join partition. *maxDepth* controls the number of levels to
traverse. *fq* is a limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edges* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="j...@company.com",
to="j...@company.com",
edge="from=to",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search starts from the node
j...@company.com and searches for the node j...@company.com, traversing the
*edge* by iteratively joining the *from* and *to* columns. Each level in the
traversal is implemented as a *parallel partitioned* nested loop join across
the entire *collection*. The *threads* parameter controls the number of threads
performing the join at each level. The *partitionSize* controls the of number
of nodes in each join partition. *maxDepth* controls the number of levels to
traverse. *fq* is a limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="j...@company.com",
to="j...@company.com",
edge="from=to",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search starts from the node
j...@company.com and searches for the node j...@company.com, traversing the
*edge* by iteratively joining the *from* and *to" columns. Each level in the
traversal is implemented as a *parallel partitioned* nested loop join across
the entire *collection*. The *threads* parameter controls the number of threads
performing the join at each level. The *partitionSize* controls the of number
of nodes in each join partition. *maxDepth* controls the number of levels to
traverse. *fq* is a limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edge* by iteratively joining the *from* and *to* columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="j...@company.com",
to="j...@company.com",
edge="from=to",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search starts from the node
j...@company.com and searches for the node j...@company.com, traversing the
*edge* by iteratively joining the *from* and *to" columns. Each level in the
traversal is implemented as a *parallel partitioned* nested loop join across
the entire *collection*. The *threads* parameter controls the number of threads
performing the join at each level. The *partitionSize* controls the of number
of nodes in each join partition. *maxDepth* controls the number of levels to
traverse. *fq* is a limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search is performed *from* node1
*to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
level in the traversal is implemented as a *parallel partitioned* nested loop
join across the entire *collection*. The *threads* parameter controls the
number of threads performing the join at each level. The *partitionSize*
controls the of number of nodes in each join partition. *maxDepth* controls the
number of levels to traverse. *fq* is a limiting query applied to each level in
the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="j...@company.com",
> to="j...@company.com",
> edge="from=to",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search starts from the node
> j...@company.com and searches for the node j...@company.com, traversing the
> *edge* by iteratively joining the *from* and *to" columns. Each level in the
> traversal is implemented as a *parallel partitioned* nested loop join across
> the entire *collection*. The *threads* parameter controls the number of
> threads performing the join at each level. The *partitionSize* controls the
> of number of nodes in each join partition. *maxDepth* controls the number of
> levels to traverse. *fq* is a limiting query applied to each level in the
> traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8875) ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in Overseer
[ https://issues.apache.org/jira/browse/SOLR-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-8875: --- Summary: ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in Overseer (was: ZkStateWriter.writePendingUpdates() can return null CollectionState; NPE in Overseer) I just pushed a branch by the name of this issue. It has one edit from SOLR-5750's branch, which is to cause an assertion failure instead of just logging an error. Simply run TestCloudBackupRestore. > ZkStateWriter.writePendingUpdates() can return null clusterState; NPE in > Overseer > - > > Key: SOLR-8875 > URL: https://issues.apache.org/jira/browse/SOLR-8875 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: David Smiley > > While trying to get the test in Varun's patch in SOLR-5750 (SolrCloud > collection backup & restore) to succeed, I kept hitting an NPE in Overseer in > which clusterState was null. I added a bunch of asserts and found where it > was happening which I worked around temporarily. See > https://github.com/apache/lucene-solr/commit/fd9c4d59e8dbe0e9fbd99a40ed2ff746c1ae7a0c#diff-9ed614eee66b9e685d73446b775dc043R247 > which is ZkStateWriter.writePendingUpdates() returning null, overwriting the > current non-null clusterState. This happens nearly every time for me when I > run that test. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8899) MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does not close.
[ https://issues.apache.org/jira/browse/SOLR-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216138#comment-15216138 ] Mark Miller commented on SOLR-8899: --- This causes issues as HttpClient can do things like start threads and needs to be closed. > MergeStrategy code creates HttpClient(s) and HttoSolrClient(s) that it does > not close. > -- > > Key: SOLR-8899 > URL: https://issues.apache.org/jira/browse/SOLR-8899 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216129#comment-15216129
]
Joel Bernstein commented on SOLR-:
--
I was suggesting that we can have both a generic approach to graph traversals
(like the ReducerStream) and specific graph expressions. Eventually the generic
approach could power the specific expression.
In the beginning it's easier to start with a couple of specific uses cases to
iron out the mechanics of how to do the distributed traversals. This will help
us come up with a generic approach.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join across the entire *collection*. The *threads* parameter controls the
> number of threads performing the join at each level. The *partitionSize*
> controls the of number of nodes in each join partition. *maxDepth* controls
> the number of levels to traverse. *fq* is a limiting query applied to each
> level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216113#comment-15216113
]
Dennis Gove edited comment on SOLR- at 3/29/16 2:46 PM:
I wasn't suggesting that the ReduceStream be used for graph traversals, just
that a similar approach to the design be used. For example,
{code}
graph(
collection,
set=node([some q and fq defining the nodes to include in graph]),
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining an ending node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
or use a stream as the input set with
{code}
graph(
streamOfTuples,
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining an ending node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
was (Author: dpgove):
I wasn't suggesting that the ReduceStream be used for graph traversals, just
that a similar approach to the design be used. For example,
{code}
graph(
collection,
set=node([some q and fq defining the nodes to include in graph]),
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining a starting node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
or use a stream as the input set with
{code}
graph(
streamOfTuples,
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining a starting node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join across the entire *collection*. The *threads* parameter controls the
> number of threads performing the join at each level. The *partitionSize*
> controls the of number of nodes in each join partition. *maxDepth* controls
> the number of levels to traverse. *fq* is a limiting query applied to each
> level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216113#comment-15216113
]
Dennis Gove commented on SOLR-:
---
I wasn't suggesting that the ReduceStream be used for graph traversals, just
that a similar approach to the design be used. For example,
{code}
graph(
collection,
set=node([some q and fq defining the nodes to include in graph]),
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining a starting node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
or use a stream as the input set with
{code}
graph(
streamOfTuples,
selector=shortestPath(
from=node([some q and fq defining a starting node or nodes]),
to=node([some q and fq defining a starting node or nodes]),
edge="fieldA=fieldB"
)
)
{code}
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join across the entire *collection*. The *threads* parameter controls the
> number of threads performing the join at each level. The *partitionSize*
> controls the of number of nodes in each join partition. *maxDepth* controls
> the number of levels to traverse. *fq* is a limiting query applied to each
> level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search is performed *from* node1
*to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
level in the traversal is implemented as a *parallel partitioned* nested loop
join across the entire *collection*. The *threads* parameter controls the
number of threads performing the join at each level. The *partitionSize*
controls the of number of nodes in each join partition. *maxDepth* controls the
number of levels to traverse. *fq* is a limiting query applied to each level in
the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search is performed *from* node1
*to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
level in the traversal is implemented as a *parallel partitioned* nested loop
join. The *threads* parameter controls the number of threads performing the
join at each level. The *partitionSize* controls the of number of nodes in each
join partition. *maxDepth* controls the number of levels to traverse. *fq* is a
limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join across the entire *collection*. The *threads* parameter controls the
> number of threads performing the join at each level. The *partitionSize*
> controls the of number of nodes in each join partition. *maxDepth* controls
> the number of levels to traverse. *fq* is a limiting query applied to each
> level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
The expression above performs a *breadth first search* to find the shortest
path in an unweighted, directed graph. The search is performed *from* node1
*to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
level in the traversal is implemented as a *parallel partitioned* nested loop
join. The *threads* parameter controls the number of threads performing the
join at each level. The *partitionSize* controls the of number of nodes in each
join partition. *maxDepth* controls the number of levels to traverse. *fq* is a
limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
Th expression above performs a *breadth first search* to find the shortest path
in an unweighted, directed graph. The search is performed *from* node1 *to*
node2, traversing the *edge* *joining* colA to colB iteratively. Each level in
the traversal is implemented as a *parallel partitioned* nested loop join. The
*threads* parameter controls the number of threads performing the join at each
level. The *partitionSize* controls the of number of nodes in each join
partition. *maxDepth* controls the number of levels to traverse. *fq* is a
limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> The expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join. The *threads* parameter controls the number of threads performing the
> join at each level. The *partitionSize* controls the of number of nodes in
> each join partition. *maxDepth* controls the number of levels to traverse.
> *fq* is a limiting query applied to each level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216080#comment-15216080
]
Joel Bernstein edited comment on SOLR- at 3/29/16 2:35 PM:
---
I think we can approach graph work in much the same way we approached
relational algebra. We have some specific streams that do joins etc... and we
have a ReducerStream which can do lot's of relational algebra on it's own.
Eventually the ReducerStream could power some of the joins like it currently
powers unique.
With graph queries we can have some specific expressions and a generic reduce
expression as well.
was (Author: joel.bernstein):
I think we can approach graph work in much the same way we approached
relational algebra. We have some specific streams that do joins etc... and we
have a ReducerStream which could can do lot's of relational algebra on it's
own. Eventually the ReducerStream could power some of the joins like it
currently powers unique.
With graph queries we can have some specific expressions and a generic reduce
expression as well.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> Th expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join. The *threads* parameter controls the number of threads performing the
> join at each level. The *partitionSize* controls the of number of nodes in
> each join partition. *maxDepth* controls the number of levels to traverse.
> *fq* is a limiting query applied to each level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8888) Add shortestPath Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-:
-
Description:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA=colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
Th expression above performs a *breadth first search* to find the shortest path
in an unweighted, directed graph. The search is performed *from* node1 *to*
node2, traversing the *edge* *joining* colA to colB iteratively. Each level in
the traversal is implemented as a *parallel partitioned* nested loop join. The
*threads* parameter controls the number of threads performing the join at each
level. The *partitionSize* controls the of number of nodes in each join
partition. *maxDepth* controls the number of levels to traverse. *fq* is a
limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
was:
This ticket is to implement a distributed shortest path graph traversal as a
Streaming Expression.
Expression syntax:
{code}
shortestPath(collection,
from="node1",
to="node2",
edge="colA, colB",
threads="6",
partitionSize="300",
fq="limiting query",
maxDepth="4")
{code}
Th expression above performs a *breadth first search* to find the shortest path
in an unweighted, directed graph. The search is performed *from* node1 *to*
node2, traversing the *edge* columns colA to colB iteratively. Each level in
the traversal is implemented as a *parallel partitioned* nested loop join. The
*threads* parameter controls the number of threads performing the join at each
level. The *partitionSize* controls the of number of nodes in each join
partition. *maxDepth* controls the number of levels to traverse. *fq* is a
limiting query applied to each level in the traversal.
Future implementations can add more capabilities such as weighted traversals.
> Add shortestPath Streaming Expression
> -
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch,
> SOLR-.patch
>
>
> This ticket is to implement a distributed shortest path graph traversal as a
> Streaming Expression.
> Expression syntax:
> {code}
> shortestPath(collection,
> from="node1",
> to="node2",
> edge="colA=colB",
> threads="6",
> partitionSize="300",
> fq="limiting query",
> maxDepth="4")
> {code}
> Th expression above performs a *breadth first search* to find the shortest
> path in an unweighted, directed graph. The search is performed *from* node1
> *to* node2, traversing the *edge* *joining* colA to colB iteratively. Each
> level in the traversal is implemented as a *parallel partitioned* nested loop
> join. The *threads* parameter controls the number of threads performing the
> join at each level. The *partitionSize* controls the of number of nodes in
> each join partition. *maxDepth* controls the number of levels to traverse.
> *fq* is a limiting query applied to each level in the traversal.
> Future implementations can add more capabilities such as weighted traversals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
