[jira] [Comment Edited] (SOLR-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700800#comment-14700800
]
Robert Krüger edited comment on SOLR-7884 at 8/18/15 6:49 AM:
--
Sorry, my bad. I didn't read SOLR-5043. The first proposed fix with the
background thread would work perfectly in my case as I don't care about the
system info at all. I am not sure if the second one would work as I do not know
under which circumstances the SystemInfoHandler is actually used. Just delaying
the hang until after application startup would actually make matters worse for
my scenario. Waiting for an app to start up slowly is one thing. Having the app
hang unexpectedly after it has started would make it look seriously broken.
was (Author: rmk_apache):
Sorry, my bad. I didn't read SOLR-5043. That would work perfectly in my case as
I don't need the system info at all. Thanks for pointing me to that again.
> Omit reverse lookups in SystemInfoHandler
> -
>
> Key: SOLR-7884
> URL: https://issues.apache.org/jira/browse/SOLR-7884
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 5.2.1
>Reporter: Robert Krüger
> Attachments: SOLR-7884.patch
>
>
> The method SystemInfoHandler.init contains this code:
> {code:java}
> try {
> InetAddress addr = InetAddress.getLocalHost();
> hostname = addr.getCanonicalHostName();
> } catch (UnknownHostException e) {
> //default to null
> }
> }
> {code}
> The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
> OSX times out after 30 seconds if the current network setup has a problem
> with reverse lookup and then returns the IP address as host name. In our
> product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
> of the container and another one for that of the core) during startup under
> these conditions. Unfortunately I have found no way to make this reproducible
> by simulating it as it depends on local network config, os and whatever else.
> As Solr is shipped bundled with a desktop application, there is currently no
> workaround because the user network configuration is beyond our reach.
> The suggested fix for this is to replace the call to getCanonicalHostName by
> one to getHostName(), which is done for exactly this purpose (obtaining a
> host string for logging) in the popular Logback framework (see
> http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
> they do it).
> Otherwise Solr has been working perfectly in this setup (bundled with a
> desktop app) for a long time and it would be great to remove that last
> obstacle to make it a nicer citizen bundlingwise.
--
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-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700800#comment-14700800
]
Robert Krüger commented on SOLR-7884:
-
Sorry, my bad. I didn't read SOLR-5043. That would work perfectly in my case as
I don't need the system info at all. Thanks for pointing me to that again.
> Omit reverse lookups in SystemInfoHandler
> -
>
> Key: SOLR-7884
> URL: https://issues.apache.org/jira/browse/SOLR-7884
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 5.2.1
>Reporter: Robert Krüger
> Attachments: SOLR-7884.patch
>
>
> The method SystemInfoHandler.init contains this code:
> {code:java}
> try {
> InetAddress addr = InetAddress.getLocalHost();
> hostname = addr.getCanonicalHostName();
> } catch (UnknownHostException e) {
> //default to null
> }
> }
> {code}
> The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
> OSX times out after 30 seconds if the current network setup has a problem
> with reverse lookup and then returns the IP address as host name. In our
> product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
> of the container and another one for that of the core) during startup under
> these conditions. Unfortunately I have found no way to make this reproducible
> by simulating it as it depends on local network config, os and whatever else.
> As Solr is shipped bundled with a desktop application, there is currently no
> workaround because the user network configuration is beyond our reach.
> The suggested fix for this is to replace the call to getCanonicalHostName by
> one to getHostName(), which is done for exactly this purpose (obtaining a
> host string for logging) in the popular Logback framework (see
> http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
> they do it).
> Otherwise Solr has been working perfectly in this setup (bundled with a
> desktop app) for a long time and it would be great to remove that last
> obstacle to make it a nicer citizen bundlingwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 (Java 7) SUCCESS! [1:02:40.331020] -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 5036 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5036/ Java: 32bit/jdk1.7.0_80 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.store.TestSleepingLockWrapper.testStressLocks Error Message: IndexWriter hit unexpected exceptions Stack Trace: java.lang.AssertionError: IndexWriter hit unexpected exceptions at __randomizedtesting.SeedInfo.seed([E01231EAB5647778:BE237F17A9C8BF1E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.store.BaseLockFactoryTestCase.testStressLocks(BaseLockFactoryTestCase.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 1767 lines...] [junit4] Suite: org.apache.lucene.store.TestSleepingLockWrapper [junit4] 1> Stress Test Index Writer: creation hit unexpected exception: java.nio.file.AccessDeniedException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSleepingLockWrapper_E01231EAB5647778-001\tempDir-003\segments_3 [junit4] 1> java.nio.file.AccessDeniedException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\core\test\J0\temp\lucene.store.TestSleepingLockWrapper_E01231EAB5647778-001\tempDir-003\segments_3 [junit4] 1>at sun.nio
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 767 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/767/ 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.FullSolrCloudDistribCmdsTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([8856DE01B6BF11DD]:0) FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([8856DE01B6BF11DD]:0) FAILED: org.apache.solr.search.TestReloadDeadlock.testReloadDeadlock Error Message: Captured an uncaught exception in thread: Thread[id=24109, name=WRITER4, state=RUNNABLE, group=TGRP-TestReloadDeadlock] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=24109, name=WRITER4, state=RUNNABLE, group=TGRP-TestReloadDeadlock] at __randomizedtesting.SeedInfo.seed([8856DE01B6BF11DD:B5D77AA0E2F4F29F]:0) Caused by: java.lang.RuntimeException: org.apache.solr.common.SolrException: Error opening new searcher at __randomizedtesting.SeedInfo.seed([8856DE01B6BF11DD]:0) at org.apache.solr.search.TestReloadDeadlock$1.run(TestReloadDeadlock.java:166) Caused by: org.apache.solr.common.SolrException: Error opening new searcher at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1673) at org.apache.solr.core.SolrCore.getRealtimeSearcher(SolrCore.java:1530) at org.apache.solr.update.VersionInfo.getVersionFromIndex(VersionInfo.java:202) at org.apache.solr.update.UpdateLog.lookupVersion(UpdateLog.java:783) at org.apache.solr.update.VersionInfo.lookupVersion(VersionInfo.java:195) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1088) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:705) at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:470) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:134) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:113) at org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:76) at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:98) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:151) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2079) at org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:131) at org.apache.solr.SolrTestCaseJ4.updateJ(SolrTestCaseJ4.java:1104) at org.apache.solr.SolrTestCaseJ4.addAndGetVersion(SolrTestCaseJ4.java:1250) at org.apache.solr.search.TestReloadDeadlock.addDoc(TestReloadDeadlock.java:200) at org.apache.solr.search.TestReloadDeadlock.access$100(TestReloadDeadlock.java:46) at org.apache.solr.search.TestReloadDeadlock$1.run(TestReloadDeadlock.java:156) Caused by: java.lang.NullPointerException at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1642) ... 21 more FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=40026, name=collection5, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=40026, name=collection5, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43978/wq/j: Could not find collection : awholynewstresscollection_collection5_1 at __randomizedtesting.SeedInfo.seed([8856DE01B6BF11DD]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13900 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13900/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: Captured an uncaught exception in thread: Thread[id=7775, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=7775, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Caused by: org.apache.solr.common.cloud.ZooKeeperException: at __randomizedtesting.SeedInfo.seed([E2DA83FDEBF8F49D]:0) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:234) Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CdcrReplicationHandlerTest_E2DA83FDEBF8F49D-001/jetty-001/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1509807146360897536 (No such file or directory) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244) at org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173) at org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610) at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877) at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:526) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:227) Caused by: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CdcrReplicationHandlerTest_E2DA83FDEBF8F49D-001/jetty-001/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1509807146360897536 (No such file or directory) at java.io.RandomAccessFile.open0(Native Method) at java.io.RandomAccessFile.open(RandomAccessFile.java:327) at java.io.RandomAccessFile.(RandomAccessFile.java:243) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236) ... 7 more Build Log: [...truncated 10585 lines...] [junit4] Suite: org.apache.solr.cloud.CdcrReplicationHandlerTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CdcrReplicationHandlerTest_E2DA83FDEBF8F49D-001/init-core-data-001 [junit4] 2> 938062 INFO (SUITE-CdcrReplicationHandlerTest-seed#[E2DA83FDEBF8F49D]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) [junit4] 2> 938062 INFO (SUITE-CdcrReplicationHandlerTest-seed#[E2DA83FDEBF8F49D]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /_c/ [junit4] 2> 938064 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 938064 INFO (Thread-3146) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 938064 INFO (Thread-3146) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 938164 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.ZkTestServer start zk server on port:40183 [junit4] 2> 938164 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 938165 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 938167 INFO (zkCallback-853-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@6b6a4185 name:ZooKeeperConnection Watcher:127.0.0.1:40183 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 938167 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 938167 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 938167 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 938168 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[E2DA83FDEBF8F49D]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProv
[jira] [Commented] (SOLR-7734) MapReduce Indexer can error when using collection
[
https://issues.apache.org/jira/browse/SOLR-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700579#comment-14700579
]
Gregory Chanan commented on SOLR-7734:
--
Looks good, I really like the new test. All of my previous comments seem to be
addressed. Just a few minor issues/comments below:
Issue #1:
When I try "ant test" I get:
{code}
[junit4]> Throwable #1: java.lang.RuntimeException: Suite class
org.apache.solr.hadoop.MiniMRTest should be a concrete class (not abstract).
{code}
Issue #2:
{code}
public void useSolrHomeDir() throws Exception {
String[] prepend = {"--solr-home-dir=" +
DROPALL_CONF_DIR.getAbsolutePath()};
{code}
you can't actually tell if this is going to zk or not. Maybe overwrite zk with
the "good" version or something beforehand?
Issue #3:
{code}
solr/contrib/morphlines-core/src/test-files/solr/dropall/conf/stopwords.txt
{code}
Do we need this file? I don't see it referenced.
Issue #4:
{code}
try (InputStream source =
MapReduceIndexerTool.class.getResourceAsStream("/solrconfig.indexer.xml");
FileOutputStream destination = new
FileOutputStream(getSolrConfig(tmpSolrHomeDir))) {
ByteStreams.copy(source, destination);
}
LOG.debug("Replaced zookeeper's solrconfig.xml with embedded
version.");
{code}
This spacing looks funky here.
Issue #5:
{code}
SolrConfigMRTest
{code}
can you put the license first? all the other test have the license first (or
after the package). I don't know if this fails the rat check or not, but seems
good to be consistent.
> MapReduce Indexer can error when using collection
> -
>
> Key: SOLR-7734
> URL: https://issues.apache.org/jira/browse/SOLR-7734
> Project: Solr
> Issue Type: Bug
> Components: contrib - MapReduce
>Affects Versions: 5.2.1
>Reporter: Mike Drob
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch,
> SOLR-7734.patch, SOLR-7734.patch
>
>
> When running the MapReduceIndexerTool, it will usually pull a
> {{solrconfig.xml}} from ZK for the collection that it is running against.
> This can be problematic for several reasons:
> * Performance: The configuration in ZK will likely have several query
> handlers, and lots of other components that don't make sense in an
> indexing-only use of EmbeddedSolrServer (ESS).
> * Classpath Resources: If the Solr services are using some kind of additional
> service (such as Sentry for auth) then the indexer will not have access to
> the necessary configurations without the user jumping through several hoops.
> * Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make
> sense. There's other configurations that
> * Update Chain Behaviours: I'm under the impression that UpdateChains may
> behave differently in ESS than a SolrCloud cluster. Is it safe to depend on
> consistent behaviour here?
--
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-7935) NPE from VersionInfo.lookupVersion during core reload
[ https://issues.apache.org/jira/browse/SOLR-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-7935: --- Attachment: SOLR-7935.patch Here's a simple patch that avoids going through the update handler to get the latest writer. > NPE from VersionInfo.lookupVersion during core reload > - > > Key: SOLR-7935 > URL: https://issues.apache.org/jira/browse/SOLR-7935 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley > Attachments: SOLR-7935.patch > > > The test from SOLR-7836 sometimes fails with a NPE where an add looks up > version info from the index. -- 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-7935) NPE from VersionInfo.lookupVersion during core reload
[ https://issues.apache.org/jira/browse/SOLR-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700561#comment-14700561 ] Yonik Seeley commented on SOLR-7935: OK, so what I think is happening here: - ulog is reused for the new core - ulog has a reference to the uhandler that is set at the end of the DUH2 constructor - a request that needs a version check comes in after the ulog.uhandler reference is set, but before the core.uhandler reference is set, leading to a NPE when it is used to try and open a new realtime searcher > NPE from VersionInfo.lookupVersion during core reload > - > > Key: SOLR-7935 > URL: https://issues.apache.org/jira/browse/SOLR-7935 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley > > The test from SOLR-7836 sometimes fails with a NPE where an add looks up > version info from the index. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 (Java 7) SUCCESS! [0:50:19.326227] Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Aug 17, 2015 at 5:16 PM, Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > +1 > (Java 7) > SUCCESS! [1:54:57.008126] > > > On Tue, Aug 18, 2015 at 2:16 AM, Anshum Gupta > wrote: > >> +1 >> >> Smoke tester is happy with both Java 7 & 8: >> >> SUCCESS! [1:18:46.151515] >> >> On Mon, Aug 17, 2015 at 5:24 AM, Noble Paul wrote: >> >>> hi all, >>> Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 >>> >>> The artifacts can be downloaded from: >>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 >>> >>> You can run the smoke tester directly with this command: >>> >>> python3 -u dev-tools/scripts/smokeTestRelease.py >>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ >>> >>> >>> -- >>> - >>> Noble Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> >> -- >> Anshum Gupta >> > >
[jira] [Commented] (SOLR-7927) Transaction log consumes lot of memory when indexing large documents
[
https://issues.apache.org/jira/browse/SOLR-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700420#comment-14700420
]
Steve Rowe commented on SOLR-7927:
--
The maximum Unicode code point (as of Unicode 8 anyway) is U+10
([http://www.unicode.org/glossary/#code_point]). This is encoded in UTF-16 as
surrogate pair {{\uDBFF\uDFFF}}, which takes up two Java chars, and is
represented in UTF-8 as the 4-byte sequence {{F4 8F BF BF}}. This is likely
where the mistaken 4-bytes-per-Java-char formulation came from: the maximum
number of UTF-8 bytes required to represent a Unicode *code point* is 4.
The maximum Java char is {{\u}}, which is represented in UTF-8 as the
3-byte sequence {{EF BF BF}}.
So I think it's safe to switch to using 3 bytes per Java char (the unit of
measurement returned by {{String.length()}}), like
{{CompressingStoredFieldsWriter.writeField()}} does.
> Transaction log consumes lot of memory when indexing large documents
>
>
> Key: SOLR-7927
> URL: https://issues.apache.org/jira/browse/SOLR-7927
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 5.2.1
>Reporter: Shalin Shekhar Mangar
> Fix For: Trunk, 5.4
>
>
> Solr is started with 1280M heap.
> ./bin/solr start -m 1280m
> Indexing a 100MB JSON file (using curl) containing large JSON documents from
> project Gutenberg fails with OOM but indexing a 549M JSON file containing
> small documents is indexed just fine.
> The same 100MB JSON file with the same heap size can be indexed just fine if
> I disable the transaction log.
--
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-7927) Transaction log consumes lot of memory when indexing large documents
[ https://issues.apache.org/jira/browse/SOLR-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700390#comment-14700390 ] Yonik Seeley commented on SOLR-7927: bq. For example, JavaBinCodec.writeStr creates a byte array of size 4 * string.length but the same can be done in 3 * string.length Hmmm, that code (the change from CESU8 & number-of-java-chars to UTF8) was done Mr Unicode Policeman, so it's interesting if it's wrong. I don't know myself if there are any 16 bit patterns (i.e. it may not be valid UTF16) that blows up to 4 bytes when encoded as UTF8... the unicode replacement character is only 3 bytes too, so I can't find anything that would result in 4x. > Transaction log consumes lot of memory when indexing large documents > > > Key: SOLR-7927 > URL: https://issues.apache.org/jira/browse/SOLR-7927 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 5.2.1 >Reporter: Shalin Shekhar Mangar > Fix For: Trunk, 5.4 > > > Solr is started with 1280M heap. > ./bin/solr start -m 1280m > Indexing a 100MB JSON file (using curl) containing large JSON documents from > project Gutenberg fails with OOM but indexing a 549M JSON file containing > small documents is indexed just fine. > The same 100MB JSON file with the same heap size can be indexed just fine if > I disable the transaction log. -- 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-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700370#comment-14700370
]
Ramkumar Aiyengar commented on SOLR-7884:
-
Robert, I think Hoss' suggestion of using SOLR-5043 works best, as it decouples
the functionality which needs the hostname (SystemInfoHandler) from core load.
If you need system info to be shown without hanging on hostname, that's
something you can discuss as an enhancement to that handler, or you could even
write your own handler which avoids these lookups. But in any case, it
shouldn't hold up core load..
> Omit reverse lookups in SystemInfoHandler
> -
>
> Key: SOLR-7884
> URL: https://issues.apache.org/jira/browse/SOLR-7884
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 5.2.1
>Reporter: Robert Krüger
> Attachments: SOLR-7884.patch
>
>
> The method SystemInfoHandler.init contains this code:
> {code:java}
> try {
> InetAddress addr = InetAddress.getLocalHost();
> hostname = addr.getCanonicalHostName();
> } catch (UnknownHostException e) {
> //default to null
> }
> }
> {code}
> The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
> OSX times out after 30 seconds if the current network setup has a problem
> with reverse lookup and then returns the IP address as host name. In our
> product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
> of the container and another one for that of the core) during startup under
> these conditions. Unfortunately I have found no way to make this reproducible
> by simulating it as it depends on local network config, os and whatever else.
> As Solr is shipped bundled with a desktop application, there is currently no
> workaround because the user network configuration is beyond our reach.
> The suggested fix for this is to replace the call to getCanonicalHostName by
> one to getHostName(), which is done for exactly this purpose (obtaining a
> host string for logging) in the popular Logback framework (see
> http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
> they do it).
> Otherwise Solr has been working perfectly in this setup (bundled with a
> desktop app) for a long time and it would be great to remove that last
> obstacle to make it a nicer citizen bundlingwise.
--
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-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700354#comment-14700354
]
Karl Wright commented on LUCENE-6699:
-
I confirmed this basic picture with the following code:
{code}
xyzb = new XYZBounds();
c.getBounds(xyzb);
GeoArea area = GeoAreaFactory.makeGeoArea(PlanetModel.SPHERE,
xyzb.getMinimumX() - 2.0 * Vector.MINIMUM_RESOLUTION,
xyzb.getMaximumX() + 2.0 * Vector.MINIMUM_RESOLUTION,
xyzb.getMinimumY() - 2.0 * Vector.MINIMUM_RESOLUTION,
xyzb.getMaximumY() + 2.0 * Vector.MINIMUM_RESOLUTION,
xyzb.getMinimumZ() - 2.0 * Vector.MINIMUM_RESOLUTION,
xyzb.getMaximumZ() + 2.0 * Vector.MINIMUM_RESOLUTION);
assertEquals(GeoArea.WITHIN, area.getRelationship(c));
{code}
This always seems to pass for me.
I believe that this problem is pervasive throughout geo3d, not just for xyz
solids. As such, it will be difficult to easily fix. Let me think on it
overnight to see if I can come up with something that makes everyone happy.
> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700336#comment-14700336 ] Karl Wright commented on LUCENE-6699: - Thanks -- I was able to reproduce at least a variant of this in one of my test cases. What is happening for me is that I'm getting back OVERLAPS instead of WITHIN. This is tricky because it's happening due to edge intersection between the XYZSolid I created and the GeoRectangle I'm looking at. But the edges really do intersect in this case -- indeed, they are on top of each other -- so I will need to think hard about how to structure the logic so that it is correct given that. In the meantime, you can probably just treat OVERLAPS and WITHIN as being comparable. > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6699: --- Attachment: LUCENE-6699.patch [~daddywri] Here's the patch that should trip the assert for you? And it's entirely possible I messed up the order of the relation! > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700292#comment-14700292 ] Karl Wright edited comment on LUCENE-6699 at 8/17/15 9:57 PM: -- So what is the code? Are you constructing an XYZSolid from the XYZBounds for the shape? The shape should definitely be contained by an XYZ solid constructed from the XYZBounds for the shape. Round off should not be a concern. It's possible, though, that you might be misinterpreting the result from getRelationship(). Either that, or some specific shape has code problems I am unaware of and need to debug. So code would help. ;-) was (Author: kwri...@metacarta.com): So what is the code? Are you constructing an XYZSolid from the XYZBounds for the shape? > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700292#comment-14700292 ] Karl Wright commented on LUCENE-6699: - So what is the code? Are you constructing an XYZSolid from the XYZBounds for the shape? > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5165 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5165/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([A628C068D7F2752F:16C78CCBA496696]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evalu
Re: [VOTE] 5.3.0 RC2
+1 (Java 7) SUCCESS! [1:54:57.008126] On Tue, Aug 18, 2015 at 2:16 AM, Anshum Gupta wrote: > +1 > > Smoke tester is happy with both Java 7 & 8: > > SUCCESS! [1:18:46.151515] > > On Mon, Aug 17, 2015 at 5:24 AM, Noble Paul wrote: > >> hi all, >> Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 >> >> The artifacts can be downloaded from: >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 >> >> You can run the smoke tester directly with this command: >> >> python3 -u dev-tools/scripts/smokeTestRelease.py >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ >> >> >> -- >> - >> Noble Paul >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > > -- > Anshum Gupta >
[jira] [Commented] (SOLR-7927) Transaction log consumes lot of memory when indexing large documents
[ https://issues.apache.org/jira/browse/SOLR-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700245#comment-14700245 ] Shalin Shekhar Mangar commented on SOLR-7927: - I apologize Yonik. Actually the test JSON file had a single document of 100MB with a huge content field and not 10 docs of 10MB as I believed earlier. Now the OOM makes more sense but I think we can shave off some extra memory usage. For example, JavaBinCodec.writeStr creates a byte array of size 4 * string.length but the same can be done in 3 * string.length as Lucene's CompressingStoredFieldsWriter.writeField() does? > Transaction log consumes lot of memory when indexing large documents > > > Key: SOLR-7927 > URL: https://issues.apache.org/jira/browse/SOLR-7927 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 5.2.1 >Reporter: Shalin Shekhar Mangar > Fix For: Trunk, 5.4 > > > Solr is started with 1280M heap. > ./bin/solr start -m 1280m > Indexing a 100MB JSON file (using curl) containing large JSON documents from > project Gutenberg fails with OOM but indexing a 549M JSON file containing > small documents is indexed just fine. > The same 100MB JSON file with the same heap size can be indexed just fine if > I disable the transaction log. -- 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-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-6629: - Attachment: (was: SOLR-6629.patch) > Watch /collections zk node on all nodes > --- > > Key: SOLR-6629 > URL: https://issues.apache.org/jira/browse/SOLR-6629 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Noble Paul > Fix For: Trunk > > Attachments: SOLR-6629.patch > > > The main clusterstate.json is refreshed/used as a poor substitute for > informing all nodes about new or deleted collections even when the collection > being created or deleted has state format > 1. When we move away from state > format 1 then we should do away with this workaround and start watching the > /collections zk node on all nodes. -- 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-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700238#comment-14700238 ] Scott Blum commented on SOLR-6629: -- Added another patch, demonstrating the Lazy Collection caching. > Watch /collections zk node on all nodes > --- > > Key: SOLR-6629 > URL: https://issues.apache.org/jira/browse/SOLR-6629 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Noble Paul > Fix For: Trunk > > Attachments: SOLR-6629.patch > > > The main clusterstate.json is refreshed/used as a poor substitute for > informing all nodes about new or deleted collections even when the collection > being created or deleted has state format > 1. When we move away from state > format 1 then we should do away with this workaround and start watching the > /collections zk node on all nodes. -- 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-6629) Watch /collections zk node on all nodes
[ https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-6629: - Attachment: SOLR-6629.patch > Watch /collections zk node on all nodes > --- > > Key: SOLR-6629 > URL: https://issues.apache.org/jira/browse/SOLR-6629 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Noble Paul > Fix For: Trunk > > Attachments: SOLR-6629.patch > > > The main clusterstate.json is refreshed/used as a poor substitute for > informing all nodes about new or deleted collections even when the collection > being created or deleted has state format > 1. When we move away from state > format 1 then we should do away with this workaround and start watching the > /collections zk node on all nodes. -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6699: --- Attachment: LUCENE-6699.patch Hmm, I added an assertion that the XYZBounds contains the shape, but the assertion fails... Or could this just be a boundary issue? > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 Smoke tester is happy with both Java 7 & 8: SUCCESS! [1:18:46.151515] On Mon, Aug 17, 2015 at 5:24 AM, Noble Paul wrote: > hi all, > Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ > > > -- > - > Noble Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Anshum Gupta
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700191#comment-14700191 ] Scott Blum commented on SOLR-5872: -- Agreed. The idea behind #2 is to serve two very different kind of configurations. a) Avoiding the overseer queue for small shard count is an optimization for deployments that have a huge number of collections, but each collection has very few shards. The process of starting up and shutting down is more efficient because each collection can be updated in a distributed manner. b) Using the overseer queue for big shard count is an optimization for deployments that have few collections, but each collection has a huge number of shards. > Eliminate overseer queue > - > > Key: SOLR-5872 > URL: https://issues.apache.org/jira/browse/SOLR-5872 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > > The overseer queue is one of the busiest points in the entire system. The > raison d'être of the queue is > * Provide batching of operations for the main clusterstate,json so that > state updates are minimized > * Avoid race conditions and ensure order > Now , as we move the individual collection states out of the main > clusterstate.json, the batching is not useful anymore. > Race conditions can easily be solved by using a compare and set in Zookeeper. > The proposed solution is , whenever an operation is required to be performed > on the clusterstate, the same thread (and of course the same JVM) > # read the fresh state and version of zk node > # construct the new state > # perform a compare and set > # if compare and set fails go to step 1 > This should be limited to all operations performed on external collections > because batching would be required for others -- 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-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700181#comment-14700181 ] Ramkumar Aiyengar commented on SOLR-5872: - (1) sounds like a good idea.. On (2), to either have people decide on the approach, or have Solr do it, we would need to know the perf characteristics of both approaches. So maintaining two implementations or not really comes down to what we are trading off against. Again, only some serious benchmarking can answer that.. > Eliminate overseer queue > - > > Key: SOLR-5872 > URL: https://issues.apache.org/jira/browse/SOLR-5872 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > > The overseer queue is one of the busiest points in the entire system. The > raison d'être of the queue is > * Provide batching of operations for the main clusterstate,json so that > state updates are minimized > * Avoid race conditions and ensure order > Now , as we move the individual collection states out of the main > clusterstate.json, the batching is not useful anymore. > Race conditions can easily be solved by using a compare and set in Zookeeper. > The proposed solution is , whenever an operation is required to be performed > on the clusterstate, the same thread (and of course the same JVM) > # read the fresh state and version of zk node > # construct the new state > # perform a compare and set > # if compare and set fails go to step 1 > This should be limited to all operations performed on external collections > because batching would be required for others -- 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-5756) A utility API to move collections from stateFormat=1 to stateFormat=2
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700178#comment-14700178 ] ASF subversion and git services commented on SOLR-5756: --- Commit 1696336 from sha...@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1696336 ] SOLR-5756: Fix for race condition between unwatch and watcher fire event > A utility API to move collections from stateFormat=1 to stateFormat=2 > - > > Key: SOLR-5756 > URL: https://issues.apache.org/jira/browse/SOLR-5756 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Fix For: Trunk, 5.4 > > Attachments: CollectionStateFormat2Test-failure-r1695176.log, > CollectionStateFormat2Test-failure.log, > CollectionStateFormat2Test-passed-r1695176.log, SOLR-5756-fix.patch, > SOLR-5756-fix.patch, SOLR-5756-fix.patch-failure.log, SOLR-5756-part2.patch, > SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch, SOLR-5756.patch, > sarowe-jenkins-Lucene-Solr-tests-trunk-1522-CollectionStateFormat2-failure.txt > > > SOLR-5473 allows creation of collection with state stored outside of > clusterstate.json. We would need an API to move existing 'internal' > collections outside -- 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-5756) A utility API to move collections from stateFormat=1 to stateFormat=2
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700174#comment-14700174 ] ASF subversion and git services commented on SOLR-5756: --- Commit 1696335 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1696335 ] SOLR-5756: Fix for race condition between unwatch and watcher fire event > A utility API to move collections from stateFormat=1 to stateFormat=2 > - > > Key: SOLR-5756 > URL: https://issues.apache.org/jira/browse/SOLR-5756 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Fix For: Trunk, 5.4 > > Attachments: CollectionStateFormat2Test-failure-r1695176.log, > CollectionStateFormat2Test-failure.log, > CollectionStateFormat2Test-passed-r1695176.log, SOLR-5756-fix.patch, > SOLR-5756-fix.patch, SOLR-5756-fix.patch-failure.log, SOLR-5756-part2.patch, > SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch, SOLR-5756.patch, > sarowe-jenkins-Lucene-Solr-tests-trunk-1522-CollectionStateFormat2-failure.txt > > > SOLR-5473 allows creation of collection with state stored outside of > clusterstate.json. We would need an API to move existing 'internal' > collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2590 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2590/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([3D61B1AB45B44391]: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:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9720 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_3D61B1AB45B44391-001/init-core-data-001 [junit4] 2> 277241 INFO (SUITE-HttpPartitionTest-seed#[3D61B1AB45B44391]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 277245 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 277245 INFO (Thread-680) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 277245 INFO (Thread-680) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 277346 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.ZkTestServer start zk server on port:49263 [junit4] 2> 277346 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 277347 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 277355 INFO (zkCallback-983-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@31f41259 name:ZooKeeperConnection Watcher:127.0.0.1:49263 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 277355 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 277355 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1AB45B44391]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 277355 INFO (TEST-HttpPartitionTest.test-seed#[3D61B1
[jira] [Updated] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6699: --- Attachment: LUCENE-6699.patch Hmm, with the attached patch, which fixes the query to not use the new XYZBounds, the test passes ... so either something is wrong in the bbox computation, or something is wrong in how the BKD tree / the query optimization uses the bbox ... > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700163#comment-14700163 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696334 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696334 ] LUCENE-6699: cleanups > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700164#comment-14700164 ] Michael McCandless commented on LUCENE-6699: Thanks [~daddywri], I committed your last patch, but I'm still seeing (different) test failures ... > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 Tested with both Java7 and Java8. SUCCESS! [0:57:25.409123] On Mon, Aug 17, 2015 at 5:54 PM, Noble Paul wrote: > hi all, > Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ > > > -- > - > Noble Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700144#comment-14700144 ] Scott Blum commented on SOLR-5872: -- At the risk of creating two code paths, here's an idea. 1) We could improve batching *significantly* at the Overseer level, to be able to batch even when the same collection isn't updated twice in a row. We just need something like a dirty list instead of only tracking the last one and the shared clusterStateModified. This could be an independent improvement. 2) When performing updates on format=2, we could use a size heuristic to decide whether or not to go through the queue. For collections with less than N shards, we could just do a local CAS loop for state update ops. For collections with more than N shares we'd just always go through the queue. > Eliminate overseer queue > - > > Key: SOLR-5872 > URL: https://issues.apache.org/jira/browse/SOLR-5872 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > > The overseer queue is one of the busiest points in the entire system. The > raison d'être of the queue is > * Provide batching of operations for the main clusterstate,json so that > state updates are minimized > * Avoid race conditions and ensure order > Now , as we move the individual collection states out of the main > clusterstate.json, the batching is not useful anymore. > Race conditions can easily be solved by using a compare and set in Zookeeper. > The proposed solution is , whenever an operation is required to be performed > on the clusterstate, the same thread (and of course the same JVM) > # read the fresh state and version of zk node > # construct the new state > # perform a compare and set > # if compare and set fails go to step 1 > This should be limited to all operations performed on external collections > because batching would be required for others -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Ref guide updates for 5.3
I'm going to be a bit delayed on getting the first RC out for the Ref Guide. This release is the first one since the CWIKI Confluence installation was upgraded and while I was initially expecting it to be trouble-free, that was misplaced hope. At the current time, the PDF drafts I have made are missing several screenshots of the Admin UI, and I'm still working through how to fix the problem. I suspect it has to do with the images being larger than the page and the new Confluence version is not handling that situation properly and scaling the images. So, I'll keep working through it to see if I can find the cause & proper solution. It might be another day or two before I can get it all straightened out. Cassandra On Thu, Aug 13, 2015 at 9:09 AM, Cassandra Targett wrote: > I'll volunteer to handle the release of the new version of the Ref Guide > for 5.3. > > I'm working on adding the new Basic authc and rule-based authz stuff so > all the new security-related stuff can be in the official guide, and I > intend to make the first RC for the Ref Guide sometime on Monday, 17 August. > > If anyone has something they're working on and want more time to finish > up, it's no problem, just let me know. > > Cassandra > > On Mon, Aug 10, 2015 at 1:49 AM, Anshum Gupta > wrote: > >> Hello everyone, >> >> With the 5.3 release around the corner, we have a bunch of undocumented >> stuff (w.r.t. the users) in the release. The link below has a list of such >> features/changes that Cassandra curated from the CHANGES.txt: >> >> https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List >> >> It would be great if we could document the stuff that we contributed, or >> even better, help documenting changes we understand so we could release the >> documentation for new features with the next release. Thanks. >> >> -- >> Anshum Gupta >> > >
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 930 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/930/
4 tests failed.
REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test
Error Message:
Captured an uncaught exception in thread: Thread[id=101104, name=collection2,
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=101104, name=collection2, state=RUNNABLE,
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:40599: collection already exists:
awholynewstresscollection_collection2_0
at __randomizedtesting.SeedInfo.seed([456BEE68EFC74744]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1574)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1595)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:888)
REGRESSION:
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
Error Message:
expected:<[{indexVersion=1439836692008,generation=2,filelist=[_1.cfe, _1.cfs,
_1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, _4.cfs, _4.si,
_5.fdt, _5.fdx, _5.fnm, _5.nvd, _5.nvm, _5.si,
_5_LuceneVarGapFixedInterval_0.doc, _5_LuceneVarGapFixedInterval_0.tib,
_5_LuceneVarGapFixedInterval_0.tiv, _6.cfe, _6.cfs, _6.si, segments_2]}]> but
was:<[{indexVersion=1439836692008,generation=2,filelist=[_1.cfe, _1.cfs, _1.si,
_2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, _4.cfs, _4.si, _5.fdt,
_5.fdx, _5.fnm, _5.nvd, _5.nvm, _5.si, _5_LuceneVarGapFixedInterval_0.doc,
_5_LuceneVarGapFixedInterval_0.tib, _5_LuceneVarGapFixedInterval_0.tiv, _6.cfe,
_6.cfs, _6.si, segments_2]},
{indexVersion=1439836692008,generation=3,filelist=[_5.fdt, _5.fdx, _5.fnm,
_5.nvd, _5.nvm, _5.si, _5_LuceneVarGapFixedInterval_0.doc,
_5_LuceneVarGapFixedInterval_0.tib, _5_LuceneVarGapFixedInterval_0.tiv, _6.cfe,
_6.cfs, _6.si, _7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si,
_7_LuceneVarGapFixedInterval_0.doc, _7_LuceneVarGapFixedInterval_0.tib,
_7_LuceneVarGapFixedInterval_0.tiv, _8.cfe, _8.cfs, _8.si, segments_3]}]>
Stack Trace:
java.lang.AssertionError:
expected:<[{indexVersion=1439836692008,generation=2,filelist=[_1.cfe, _1.cfs,
_1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, _4.cfs, _4.si,
_5.fdt, _5.fdx, _5.fnm, _5.nvd, _5.nvm, _5.si,
_5_LuceneVarGapFixedInterval_0.doc, _5_LuceneVarGapFixedInterval_0.tib,
_5_LuceneVarGapFixedInterval_0.tiv, _6.cfe, _6.cfs, _6.si, segments_2]}]> but
was:<[{indexVersion=1439836692008,generation=2,filelist=[_1.cfe, _1.cfs, _1.si,
_2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, _4.cfs, _4.si, _5.fdt,
_5.fdx, _5.fnm, _5.nvd, _5.nvm, _5.si, _5_LuceneVarGapFixedInterval_0.doc,
_5_LuceneVarGapFixedInterval_0.tib, _5_LuceneVarGapFixedInterval_0.tiv, _6.cfe,
_6.cfs, _6.si, segments_2]},
{indexVersion=1439836692008,generation=3,filelist=[_5.fdt, _5.fdx, _5.fnm,
_5.nvd, _5.nvm, _5.si, _5_LuceneVarGapFixedInterval_0.doc,
_5_LuceneVarGapFixedInterval_0.tib, _5_LuceneVarGapFixedInterval_0.tiv, _6.cfe,
_6.cfs, _6.si, _7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si,
_7_LuceneVarGapFixedInterval_0.doc, _7_LuceneVarGapFixedInterval_0.tib,
_7_LuceneVarGapFixedInterval_0.tiv, _8.cfe, _8.cfs, _8.si, segments_3]}]>
at
__randomizedtesting.SeedInfo.seed([456BEE68EFC74744:60BCF5589F8F4947]: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:147)
at
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload(TestReplicationHandler.java:1138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAcce
[JENKINS-EA] Lucene-Solr-5.3-Linux (32bit/jdk1.9.0-ea-b60) - Build # 84 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/84/ Java: 32bit/jdk1.9.0-ea-b60 -client -XX:+UseConcMarkSweepGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([8379E52B0A059AD7]: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:236) at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10665 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-5.3-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.HttpPartitionTest_8379E52B0A059AD7-001/init-core-data-001 [junit4] 2> 716229 INFO (SUITE-HttpPartitionTest-seed#[8379E52B0A059AD7]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 716233 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 716237 INFO (Thread-1848) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 716237 INFO (Thread-1848) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 716337 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.ZkTestServer start zk server on port:55985 [junit4] 2> 716339 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 716345 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 716347 INFO (zkCallback-520-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@394ad0 name:ZooKeeperConnection Watcher:127.0.0.1:55985 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 716347 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 716347 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 716347 INFO (TEST-HttpPartitionTest.test-seed#[8379E52B0A059AD7]) [] o.a.s.c.c.SolrZkClient makePath: /so
[jira] [Updated] (SOLR-5756) A utility API to move collections from stateFormat=1 to stateFormat=2
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-fix.patch A real fix, I'm pretty sure. I found the race condition that was causing the flakiness. > A utility API to move collections from stateFormat=1 to stateFormat=2 > - > > Key: SOLR-5756 > URL: https://issues.apache.org/jira/browse/SOLR-5756 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Fix For: Trunk, 5.4 > > Attachments: CollectionStateFormat2Test-failure-r1695176.log, > CollectionStateFormat2Test-failure.log, > CollectionStateFormat2Test-passed-r1695176.log, SOLR-5756-fix.patch, > SOLR-5756-fix.patch, SOLR-5756-fix.patch-failure.log, SOLR-5756-part2.patch, > SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch, SOLR-5756.patch, > sarowe-jenkins-Lucene-Solr-tests-trunk-1522-CollectionStateFormat2-failure.txt > > > SOLR-5473 allows creation of collection with state stored outside of > clusterstate.json. We would need an API to move existing 'internal' > collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2639 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2639/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([B16B7B33D9E4BEA1:162FC397B45FAD18]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationWithTruncatedTlog(CdcrReplicationHandlerTest.java:121) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.Statement
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13895 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13895/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest.test Error Message: Shards in the state does not match what we set:0 vs 4 Stack Trace: java.lang.AssertionError: Shards in the state does not match what we set:0 vs 4 at __randomizedtesting.SeedInfo.seed([1D509ECC4E33E9DB:9504A116E0CF8423]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9195 lines...] [junit4] Suite: org.apache.solr.cloud.LeaderInitiatedRecoveryOnCommitTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.LeaderInitiatedRecoveryOnCommitTest_1D509ECC4E33E9DB-001/init-core-data-001 [junit4] 2> 9321 INFO (SUITE-LeaderInitiatedRecoveryOnCommitTest-seed#[1D509ECC4E33E9DB]-worker) [ ] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 9333 INFO (TEST-LeaderInitiatedRecoveryOnCommitTest.test-seed#[1D
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699905#comment-14699905
]
Michael Sun commented on SOLR-7746:
---
Attach a fix. For the ping request particular, there is a requirement that qt
parameter either be a meaningful handler or be null. The fix address this
requirement when requests are sent to shards.
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
> Attachments: SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE&name=test2&numShards=2&replicationFactor=1&maxShardsPerNode=2&collection.configName=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json&distrib=true&indent=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {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] [Updated] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Sun updated SOLR-7746:
--
Attachment: SOLR-7746.patch
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
> Attachments: SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE&name=test2&numShards=2&replicationFactor=1&maxShardsPerNode=2&collection.configName=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json&distrib=true&indent=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {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] [Updated] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch And, yet another patch which cleans up stuff > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch [~mikemccand]: Here's an updated patch that has a fix for the problem I discovered. > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
SUCCESS! 2:38:50.471225 On Mon, Aug 17, 2015 at 9:17 PM, Timothy Potter wrote: > +1 > > SUCCESS! [1:31:49.158753] tested Java 7 & 8 > > On Mon, Aug 17, 2015 at 9:46 AM, Steve Rowe wrote: >> +1 >> >> SUCCESS! [0:24:10.371290] >> >> Lucene and Solr docs, changes and javadocs look good. >> >> Steve >> >>> On Aug 17, 2015, at 8:24 AM, Noble Paul wrote: >>> >>> hi all, >>> Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 >>> >>> The artifacts can be downloaded from: >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 >>> >>> You can run the smoke tester directly with this command: >>> >>> python3 -u dev-tools/scripts/smokeTestRelease.py >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ >>> >>> >>> -- >>> - >>> Noble Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5164 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5164/ Java: 64bit/jdk1.8.0_51 -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([4338B8C5BEFDF99A:CB6C871F10019462]: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:141) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAf
[jira] [Resolved] (SOLR-7937) Solr flushes "documentCache" whenever document added/updated to collection
[ https://issues.apache.org/jira/browse/SOLR-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-7937. -- Resolution: Invalid >From a user's list post bay Maulin, the soft commit interval was set to 50 ms, >so I'll assume that was the issue. If not, we can reopen. Maulin: It's usually a good practice to ask questions you aren't _sure_ are code issues on the user's list first, _then_ raise a JIRA if the discussion points to a code issue. > Solr flushes "documentCache" whenever document added/updated to collection > -- > > Key: SOLR-7937 > URL: https://issues.apache.org/jira/browse/SOLR-7937 > Project: Solr > Issue Type: Bug >Affects Versions: 5.2 >Reporter: Maulin > > Solr flushes all documents of "documentCache" whenever new document > added/updated to collection. This impacts the query performance. -- 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-7937) Solr flushes "documentCache" whenever document added/updated to collection
[ https://issues.apache.org/jira/browse/SOLR-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699728#comment-14699728 ] Erick Erickson commented on SOLR-7937: -- Hmm, if you've tracked it that far, it would be helpful if you pointed to the code that does this so someone else doesn't have to do the detective work all over again. Thanks! > Solr flushes "documentCache" whenever document added/updated to collection > -- > > Key: SOLR-7937 > URL: https://issues.apache.org/jira/browse/SOLR-7937 > Project: Solr > Issue Type: Bug >Affects Versions: 5.2 >Reporter: Maulin > > Solr flushes all documents of "documentCache" whenever new document > added/updated to collection. This impacts the query performance. -- 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-7921) techproducts example broken; dir with spaces; Linux/Windows
[
https://issues.apache.org/jira/browse/SOLR-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699724#comment-14699724
]
Erick Erickson commented on SOLR-7921:
--
bq: when it fixes a never-released bug?
I can argue either way, I don't think there's a hard and fast rule. I usually
guess how many people are impacted by it and decide on that basis. IOW, "it's
up to you".
> techproducts example broken; dir with spaces; Linux/Windows
> ---
>
> Key: SOLR-7921
> URL: https://issues.apache.org/jira/browse/SOLR-7921
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Ishan Chattopadhyaya
>Assignee: Timothy Potter
>Priority: Blocker
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7921.patch, SOLR-7921.patch, SOLR-7921.patch,
> SOLR-7921.patch, SOLR-7921.patch
>
>
> After [~thetaphi] reported that the error with spaces in dir names
> (SOLR-7016) has reappeared in 5.3.0 RC1, I checked the same on Linux and
> found it is broken. Here's the console log:
> {noformat}
> [ishan@localhost solr 530]$ bin/solr start -e techproducts
> Creating Solr home directory /home/ishan/solr 530/example/techproducts/solr
> Starting up Solr on port 8983 using command:
> bin/solr start -p 8983 -s "example/techproducts/solr"
> NOTE: Please install lsof as this script needs it to determine if Solr is
> listening on port 8983.
> Started Solr server on port 8983 (pid=2404). Happy searching!
> Setup new core instance directory:
> /home/ishan/solr 530/example/techproducts/solr/techproducts
> Creating new core 'techproducts' using command:
> http://localhost:8983/solr/admin/cores?action=CREATE&name=techproducts&instanceDir=techproducts
> {
> "responseHeader":{
> "status":0,
> "QTime":2671},
> "core":"techproducts"}
> Indexing tech product example docs from /home/ishan/solr
> 530/example/exampledocs
> Error: Unable to access jarfile /home/ishan/solr
> ERROR: Process exited with an error: 1 (Exit value: 1)
> {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
Re: [VOTE] 5.3.0 RC2
+1 SUCCESS! [1:31:49.158753] tested Java 7 & 8 On Mon, Aug 17, 2015 at 9:46 AM, Steve Rowe wrote: > +1 > > SUCCESS! [0:24:10.371290] > > Lucene and Solr docs, changes and javadocs look good. > > Steve > >> On Aug 17, 2015, at 8:24 AM, Noble Paul wrote: >> >> hi all, >> Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 >> >> The artifacts can be downloaded from: >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 >> >> You can run the smoke tester directly with this command: >> >> python3 -u dev-tools/scripts/smokeTestRelease.py >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ >> >> >> -- >> - >> Noble Paul >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] 5.3.0 RC2
+1 SUCCESS! [0:24:10.371290] Lucene and Solr docs, changes and javadocs look good. Steve > On Aug 17, 2015, at 8:24 AM, Noble Paul wrote: > > hi all, > Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ > > > -- > - > Noble Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699711#comment-14699711 ] Karl Wright commented on LUCENE-6699: - They are not expected to be null. I have a fix for the problem (happened to hit it myself just moments ago). > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch Some tests and some fixes > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-7936) Bogus failure when deleting collections.
[
https://issues.apache.org/jira/browse/SOLR-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699707#comment-14699707
]
Erick Erickson commented on SOLR-7936:
--
[~shalinmangar] This was with code from last night. The CDCR failures have been
around for quite a while, although SOLR-5756 probably didn't help.
> Bogus failure when deleting collections.
>
>
> Key: SOLR-7936
> URL: https://issues.apache.org/jira/browse/SOLR-7936
> Project: Solr
> Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> When looking at the CDCR test failures, we began to wonder whether the
> problem was
> 1> the cdcr code itself
> 2> the test framework
> 3> Solr
> Some of the failures seem to be "impossible" assuming collection
> creation/deletion work OK.
> So I wrote a little program to exercise collection creation/deletion outside
> the test framework by just adding and deleting the same collection over and
> over and over again, and it started regularly failing in
> OverseerCollectionMessageHandler.deleteCollection about line 780 it would
> throw the "Could not fully remove the collection" exception:
> {code}
> TimeOut timeout = new TimeOut(30, TimeUnit.SECONDS);
> boolean removed = false;
> while (! timeout.hasTimedOut()) {
> Thread.sleep(100);
> // WORKS SO FAR IF UNCOMMENTED zkStateReader.updateClusterState();
> removed = !zkStateReader.getClusterState().hasCollection(collection);
> if (removed) {
> Thread.sleep(500); // just a bit of time so it's more likely other
> // readers see on return
> break;
> }
> }
> if (!removed) {
> throw new SolrException(ErrorCode.SERVER_ERROR,
> "Could not fully remove collection: " + collection);
> }
> {code}
> However, the collection is really gone from clusterstate. When I put the
> updateClusterState() in above, it doesn't seem to fail. Is it as simple as
> the updateClusterState() call?
> Without the update in place, it failed within 20 reps very regularly. So far,
> with the update in place we're at 132 and counting. Any comments?
> If this runs 1,000 times tonight, I'll check it in if there are no
> objections. I don't know what it means for CDCR yet though.
> I'm also suspicious of the 500ms sleep. Anyone have a clue what that's in
> there for?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7807) Change CDCR tests to "Nightly" after they bake a bit.
[ https://issues.apache.org/jira/browse/SOLR-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-7807. -- Resolution: Fixed Fix Version/s: 5.4 Trunk Mark already did this. > Change CDCR tests to "Nightly" after they bake a bit. > - > > Key: SOLR-7807 > URL: https://issues.apache.org/jira/browse/SOLR-7807 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: Trunk, 5.4 > > -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699693#comment-14699693 ] Uwe Schindler commented on SOLR-7920: - bq. SOLR-7920 is correctly listed under 5.3 in branch lucene_solr_5_3 but under 5.4 in branch_5x and trunk That was discussed before. The changes entries need to be moved NOW. Maybe this causes the confusing stuff. In any case, the release manager should check the CHANGES.txt after the relaese and remove duplicates and sync them between release, branch_5x and trunk branches. I did this on every release that I managed. > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13894 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13894/ Java: 32bit/jdk1.8.0_60-ea-b24 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: Index: 0, Size: 0 Stack Trace: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at __randomizedtesting.SeedInfo.seed([92C92FE6CC0DB3E:FE5F7CA6AA2874D8]:0) at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9234 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicatio
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699647#comment-14699647
]
Michael McCandless commented on LUCENE-6699:
OK I fixed the query to use the new XYZBounds API, but I hit NPE:
{noformat}
[junit4] Suite: org.apache.lucene.bkdtree3d.TestGeo3DPointField
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestGeo3DPointField
-Dtests.method=testBasic -Dtests.seed=1600287909381DEB -Dtests.locale=el_CY
-Dtests.timezone=America/Mexico_City -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.22s J0 | TestGeo3DPointField.testBasic <<<
[junit4]> Throwable #1: java.lang.NullPointerException
[junit4]>at
__randomizedtesting.SeedInfo.seed([1600287909381DEB:BDFA356CD6E49BC5]:0)
[junit4]>at
org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.scorer(PointInGeo3DShapeQuery.java:102)
[junit4]>at
org.apache.lucene.search.Weight.bulkScorer(Weight.java:135)
[junit4]>at
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
[junit4]>at
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
[junit4]>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:618)
[junit4]>at
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
[junit4]>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:425)
[junit4]>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:544)
[junit4]>at
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:402)
[junit4]>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:413)
[junit4]>at
org.apache.lucene.bkdtree3d.TestGeo3DPointField.testBasic(TestGeo3DPointField.java:90)
[junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}
Is it expected that sometimes the bounds would be null? If so, I could just
swap in Integer.MIN/MAX_VALUE for that dimension... (seems like in this failure
it's only the z dimension that's null).
> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699644#comment-14699644 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696305 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696305 ] LUCENE-6699: use bbox, but test fails > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699611#comment-14699611 ] Michael McCandless commented on LUCENE-6699: Thanks [~daddywri], I'll try using the bounds in the BKD tree ... and I committed your last patch! > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699610#comment-14699610 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696299 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696299 ] LUCENE-6699: remove unused code > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-7920: -- Fix Version/s: (was: 5.4) > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7938) MergeStream to support N streams
[
https://issues.apache.org/jira/browse/SOLR-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-7938:
--
Attachment: SOLR-7938.patch
> MergeStream to support N streams
>
>
> Key: SOLR-7938
> URL: https://issues.apache.org/jira/browse/SOLR-7938
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
> Labels: streaming
> Attachments: SOLR-7938.patch
>
>
> Enhances MergeStream to support merging N streams. This was previously
> limited to merging just two streams but with this enhancement it can now
> accept any number of streams to merge.
> Based on the comparator, if more than one stream could provide the next value
> then the selected value will follow the order of the streams as they appear
> in the expression or were added to the MergeStream object.
> {code}
> merge(
> search(collection1, q="id:(0 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(1)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> on="a_f asc"
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13893 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13893/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -Djava.locale.providers=JRE,SPI 2 tests failed. FAILED: org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection Error Message: Delete action failed! Stack Trace: java.lang.AssertionError: Delete action failed! at __randomizedtesting.SeedInfo.seed([E214049914065759:F17736F62569EEFF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169) at org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapt
[jira] [Updated] (SOLR-7938) MergeStream to support N streams
[
https://issues.apache.org/jira/browse/SOLR-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Gove updated SOLR-7938:
--
Issue Type: Improvement (was: Bug)
> MergeStream to support N streams
>
>
> Key: SOLR-7938
> URL: https://issues.apache.org/jira/browse/SOLR-7938
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
> Labels: streaming
>
> Enhances MergeStream to support merging N streams. This was previously
> limited to merging just two streams but with this enhancement it can now
> accept any number of streams to merge.
> Based on the comparator, if more than one stream could provide the next value
> then the selected value will follow the order of the streams as they appear
> in the expression or were added to the MergeStream object.
> {code}
> merge(
> search(collection1, q="id:(0 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(1)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> on="a_f asc"
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7938) MergeStream to support N streams
Dennis Gove created SOLR-7938:
-
Summary: MergeStream to support N streams
Key: SOLR-7938
URL: https://issues.apache.org/jira/browse/SOLR-7938
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: Trunk
Reporter: Dennis Gove
Priority: Minor
Enhances MergeStream to support merging N streams. This was previously limited
to merging just two streams but with this enhancement it can now accept any
number of streams to merge.
Based on the comparator, if more than one stream could provide the next value
then the selected value will follow the order of the streams as they appear in
the expression or were added to the MergeStream object.
{code}
merge(
search(collection1, q="id:(0 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
asc"),
search(collection1, q="id:(1)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s asc"),
search(collection1, q="id:(2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s asc"),
on="a_f asc"
)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699571#comment-14699571 ] Uwe Schindler commented on SOLR-7920: - I see it listed in CHANGES.txt, just search for "7920" in the changes.txt: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/changes/Changes.html > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699574#comment-14699574 ] Uwe Schindler commented on SOLR-7920: - It went in! > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch patch to remove unused code > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699563#comment-14699563
]
Karl Wright commented on LUCENE-6699:
-
FWIW, [~mikemccand], I convinced myself that the one case I was worried about
should, in fact, not be an issue. So you should be able to start using
XYZBounds to obtain bounds information for shapes.
Specifically, you want to do this:
{code}
XYZBounds bounds = new XYZBounds();
myshape.getBounds(bounds);
double minX = bounds.getMinimumX();
...
{code}
I will work on the tests shortly, but that's basically all there should be to
it. Please let me know if you find any weird behavior.
> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699561#comment-14699561 ] Karl Wright commented on LUCENE-6699: - It all looks OK. I don't know why svn was unhappy. Maybe I should rebuild my workarea... > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699554#comment-14699554 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696276 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696276 ] LUCENE-6699: round up when dividing by 2 to find size of BKD tree > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699546#comment-14699546
]
Michael McCandless commented on LUCENE-6699:
[~daddywri] I committed the patch but svn got a bit furious:
{noformat}
mike@haswell:/l/3dbkd$ svn patch patch.x
U
lucene/spatial/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java
C
lucene/spatial/src/test/org/apache/lucene/spatial/spatial4j/Geo3dShapeRectRelationTestCase.java
> rejected hunk @@ -58,7 +58,8 @@
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/Bounds.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoBaseShape.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoCircle.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoCompositeMembershipShape.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoConvexPolygon.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateHorizontalLine.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateLatitudeZone.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateLongitudeSlice.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegeneratePoint.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateVerticalLine.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoLatitudeZone.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoLongitudeSlice.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoNorthLatitudeZone.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoNorthRectangle.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoPath.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoRectangle.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoShape.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoSouthLatitudeZone.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoSouthRectangle.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideDegenerateHorizontalLine.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideLongitudeSlice.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideNorthRectangle.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideRectangle.java
U
lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideSouthRectangle.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWorld.java
A lucene/spatial3d/src/java/org/apache/lucene/geo3d/LatLonBounds.java
U lucene/spatial3d/src/java/org/apache/lucene/geo3d/Plane.java
A lucene/spatial3d/src/java/org/apache/lucene/geo3d/XYZBounds.java
> hunk @@ -138,7 +138,7 @@ already applied
> hunk @@ -145,6 +145,7 @@ already applied
> hunk @@ -154,6 +155,7 @@ already applied
> hunk @@ -160,12 +162,12 @@ already applied
> hunk @@ -81,7 +81,7 @@ already applied
> hunk @@ -88,6 +88,7 @@ already applied
> hunk @@ -96,18 +97,13 @@ already applied
U lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoBBoxTest.java
U lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoCircleTest.java
U
lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoConvexPolygonTest.java
U lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoModelTest.java
U lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoPathTest.java
U lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoPolygonTest.java
> hunk @@ -27,16 +27,15 @@ already applied
> hunk @@ -67,5 +66,160 @@ already applied
Summary of conflicts:
Text conflicts: 1
{noformat}
I resolved the one conflict by hand, but can you svn up and confirm things look
OK? Tests did pass after applying the patch...
> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699545#comment-14699545 ] ASF subversion and git services commented on LUCENE-6699: - Commit 1696275 from [~mikemccand] in branch 'dev/branches/lucene6699' [ https://svn.apache.org/r1696275 ] LUCENE-6699: first cut to support x,y,z bounds > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699543#comment-14699543 ] Michael McCandless commented on LUCENE-6699: Thanks [~daddywri], I'll commit shortly. I ran the same "225 bboxes around London on the 61M OpenStreetMap lat/lon points" perf tests with the current branch, plus the 3 other existing options: * Geo3D + BKD (PointInGeo3DShapeQuery, this issue/branch): index is 936 MB, took 423 + 96 (close, waiting for merges) sec to build. 7.01 sec to run 225 queries, total hits 221,118,860. * 2D BKD (BKDPointInBBoxQuery): index is 704 MB, took 163 + 97 sec to build. 2.32 sec to run 225 queries, total hits 221,118,844. It's OK (I think) that number of hits is a wee bit smaller than geo3d because the geo3d bbox when projected to 2D space is a bit bowed out (I think?) and can therefore include a few more points. * Postings + DV (GeoPointInBBoxQuery): index is 3.4 GB, took 349 + 11 sec to build. 3.60 sec to run 225 queries, total 221,120,393 hits (hmm: I'm not sure why this is not identical to 2D BKD?) * PackedQuadPrefixTree (RecursivePrefixTreeStrategy), with maxLevels=25: 990 + 11 seconds to build, 7.7 GB, 3.82 seconds to run 225 queries, total 221,123,206 hits. All these benchmarks are in luceneutil. > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699528#comment-14699528 ] Jan Høydahl commented on SOLR-7920: --- SOLR-7920 is correctly listed under 5.3 in branch lucene_solr_5_3 but under 5.4 in branch_5x and trunk > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6699: Attachment: LUCENE-6699.patch Revamp how we do bounds, so we can compute (x,y,z) bounds cheaply too. This patch has a couple of known issues, and needs tests too, both of which I'll be addressing shortly. > Integrate lat/lon BKD and spatial3d > --- > > Key: LUCENE-6699 > URL: https://issues.apache.org/jira/browse/LUCENE-6699 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, > LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch > > > I'm opening this for discussion, because I'm not yet sure how to do > this integration, because of my ignorance about spatial in general and > spatial3d in particular :) > Our BKD tree impl is very fast at doing lat/lon shape intersection > (bbox, polygon, soon distance: LUCENE-6698) against previously indexed > points. > I think to integrate with spatial3d, we would first need to record > lat/lon/z into doc values. Somewhere I saw discussion about how we > could stuff all 3 into a single long value with acceptable precision > loss? Or, we could use BinaryDocValues? We need all 3 dims available > to do the fast per-hit query time filtering. > But, second: what do we index into the BKD tree? Can we "just" index > earth surface lat/lon, and then at query time is spatial3d able to > give me an enclosing "surface lat/lon" bbox for a 3d shape? Or > ... must we index all 3 dimensions into the BKD tree (seems like this > could be somewhat wasteful)? -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699508#comment-14699508 ] Upayavira commented on SOLR-7920: - [~noble.paul] see above "Commit 1696213 from Upayavira in branch 'dev/branches/lucene_solr_5_3'". I should have waited until 5.3 was complete, before committing into the _5_3 branch. However, it did sneak in. It was the smallest of tweaks though, and pretty innocuous. The only thing is, it isn't in the 5.3 CHANGES.txt section. I'll fix that, but it won't be in it for this release. IMO, this is no big deal and we should proceed with the vote as it is currently running. > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699506#comment-14699506 ] Noble Paul commented on SOLR-7920: -- it did not go into RC2 right ?. I don't see any commits related to this JIRA > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699466#comment-14699466 ] Uwe Schindler commented on SOLR-7920: - Hi, its in the RC2 created a minute ago. So you can move the changes entries: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/changes/Changes.html > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-7920: Fix Version/s: 5.3 > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.3, 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_51) - Build # 5033 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5033/ Java: 32bit/jdk1.8.0_51 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionStateFormat2Test.test Error Message: Error from server at http://127.0.0.1:58513/osc/sk: Could not find collection : myExternColl Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:58513/osc/sk: Could not find collection : myExternColl at __randomizedtesting.SeedInfo.seed([B275EDC62FA3FE8D:3A21D21C815F9375]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionStateFormat2Test.testZkNodeLocation(CollectionStateFormat2Test.java:84) at org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOve
[VOTE] 5.3.0 RC2
hi all, Please vote for the 2nd release candidate for Lucene/Solr 5.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229 You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/ -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7921) techproducts example broken; dir with spaces; Linux/Windows
[
https://issues.apache.org/jira/browse/SOLR-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699393#comment-14699393
]
Jan Høydahl commented on SOLR-7921:
---
Is it best practice for this bug (and SOLR-7934) to have an entry under "Bug
fixes" in CHANGES.TXT, when it fixes a never-released bug?
> techproducts example broken; dir with spaces; Linux/Windows
> ---
>
> Key: SOLR-7921
> URL: https://issues.apache.org/jira/browse/SOLR-7921
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Ishan Chattopadhyaya
>Assignee: Timothy Potter
>Priority: Blocker
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7921.patch, SOLR-7921.patch, SOLR-7921.patch,
> SOLR-7921.patch, SOLR-7921.patch
>
>
> After [~thetaphi] reported that the error with spaces in dir names
> (SOLR-7016) has reappeared in 5.3.0 RC1, I checked the same on Linux and
> found it is broken. Here's the console log:
> {noformat}
> [ishan@localhost solr 530]$ bin/solr start -e techproducts
> Creating Solr home directory /home/ishan/solr 530/example/techproducts/solr
> Starting up Solr on port 8983 using command:
> bin/solr start -p 8983 -s "example/techproducts/solr"
> NOTE: Please install lsof as this script needs it to determine if Solr is
> listening on port 8983.
> Started Solr server on port 8983 (pid=2404). Happy searching!
> Setup new core instance directory:
> /home/ishan/solr 530/example/techproducts/solr/techproducts
> Creating new core 'techproducts' using command:
> http://localhost:8983/solr/admin/cores?action=CREATE&name=techproducts&instanceDir=techproducts
> {
> "responseHeader":{
> "status":0,
> "QTime":2671},
> "core":"techproducts"}
> Indexing tech product example docs from /home/ishan/solr
> 530/example/exampledocs
> Error: Unable to access jarfile /home/ishan/solr
> ERROR: Process exited with an error: 1 (Exit value: 1)
> {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
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13892 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13892/ Java: 32bit/jdk1.9.0-ea-b60 -client -XX:+UseG1GC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([5C6908E6811E5BEE:FB2DB042ECA54857]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.Stateme
[JENKINS] Lucene-Solr-NightlyTests-5.3 - Build # 7 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.3/7/ 4 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=53555, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=53555, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:44540/k_t/yn: Could not find collection : awholynewstresscollection_collection3_0 at __randomizedtesting.SeedInfo.seed([1FB1272CD8B4CB56]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:894) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestDynamicLoading Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([1FB1272CD8B4CB56]:0) at org.apache.lucene.util.TestRuleRestoreSystemProperties.before(TestRuleRestoreSystemProperties.java:53) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.handler.component.BadComponentTest Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space FAILED: junit.framework.TestSuite.org.apache.solr.schema.DocValuesMultiTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([1FB1272CD8B4CB56]:0) Build Log: [...truncated 10660 lines...] [junit4] Suite: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.3/solr/build/solr-core/test/J0/temp/solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest_1FB1272CD8B4CB56-001/init-core-data-001 [junit4] 2> 948918 INFO (SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[1FB1272CD8B4CB56]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) [junit4] 2> 948918 INFO (SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[1FB1272CD8B4CB56]-worker) [ ] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /k_t/yn [junit4] 2> 949572 WARN (SUITE-HdfsCollectionsAPIDistributed
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5163 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5163/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.test Error Message: Error from server at http://127.0.0.1:54636/checkStateVerCol: no servers hosting shard: shard1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:54636/checkStateVerCol: no servers hosting shard: shard1 at __randomizedtesting.SeedInfo.seed([7AE9E4D4B25D2806:F2BDDB0E1CA145FE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.stateVersionParamTest(CloudSolrClientTest.java:542) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13891 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13891/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([E2FFD4541B2D98C4:45BB6CF076968B7D]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(St
[jira] [Commented] (SOLR-7884) Omit reverse lookups in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699348#comment-14699348
]
Robert Krüger commented on SOLR-7884:
-
Would, as an alternative solution something like a system property that
disables the canonical name retrieval, be OK?
> Omit reverse lookups in SystemInfoHandler
> -
>
> Key: SOLR-7884
> URL: https://issues.apache.org/jira/browse/SOLR-7884
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 5.2.1
>Reporter: Robert Krüger
> Attachments: SOLR-7884.patch
>
>
> The method SystemInfoHandler.init contains this code:
> {code:java}
> try {
> InetAddress addr = InetAddress.getLocalHost();
> hostname = addr.getCanonicalHostName();
> } catch (UnknownHostException e) {
> //default to null
> }
> }
> {code}
> The call to getCanonicalHostName triggers a DNS reverse lookup, that on Mac
> OSX times out after 30 seconds if the current network setup has a problem
> with reverse lookup and then returns the IP address as host name. In our
> product this leads to a hang of 2x30 seconds (one for the SystemInfoHandler
> of the container and another one for that of the core) during startup under
> these conditions. Unfortunately I have found no way to make this reproducible
> by simulating it as it depends on local network config, os and whatever else.
> As Solr is shipped bundled with a desktop application, there is currently no
> workaround because the user network configuration is beyond our reach.
> The suggested fix for this is to replace the call to getCanonicalHostName by
> one to getHostName(), which is done for exactly this purpose (obtaining a
> host string for logging) in the popular Logback framework (see
> http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html, how
> they do it).
> Otherwise Solr has been working perfectly in this setup (bundled with a
> desktop app) for a long time and it would be great to remove that last
> obstacle to make it a nicer citizen bundlingwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13640 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13640/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.cloud.HttpPartitionTest.test
Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms!
ClusterState: { "c8n_1x2":{ "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node1":{ "base_url":"http://127.0.0.1:43415/o_/wq";,
"core":"c8n_1x2_shard1_replica1",
"node_name":"127.0.0.1:43415_o_%2Fwq", "state":"active",
"leader":"true"}, "core_node2":{
"base_url":"http://127.0.0.1:41211/o_/wq";,
"core":"c8n_1x2_shard1_replica2",
"node_name":"127.0.0.1:41211_o_%2Fwq", "state":"active",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false", "replicationFactor":"2"}, "collection1":{
"shards":{ "shard1":{ "range":"8000-",
"state":"active", "replicas":{ "core_node1":{
"base_url":"http://127.0.0.1:41211/o_/wq";, "core":"collection1",
"node_name":"127.0.0.1:41211_o_%2Fwq", "state":"active",
"leader":"true"}, "core_node3":{
"base_url":"http://127.0.0.1:40576/o_/wq";, "core":"collection1",
"node_name":"127.0.0.1:40576_o_%2Fwq",
"state":"active"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{"core_node2":{
"base_url":"http://127.0.0.1:43415/o_/wq";, "core":"collection1",
"node_name":"127.0.0.1:43415_o_%2Fwq", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false",
"autoCreated":"true", "replicationFactor":"1"}, "control_collection":{
"shards":{"shard1":{ "range":"8000-7fff",
"state":"active", "replicas":{"core_node1":{
"base_url":"http://127.0.0.1:46370/o_/wq";, "core":"collection1",
"node_name":"127.0.0.1:46370_o_%2Fwq", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false",
"autoCreated":"true", "replicationFactor":"1"}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 3 ms! ClusterState: {
"c8n_1x2":{
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node1":{
"base_url":"http://127.0.0.1:43415/o_/wq";,
"core":"c8n_1x2_shard1_replica1",
"node_name":"127.0.0.1:43415_o_%2Fwq",
"state":"active",
"leader":"true"},
"core_node2":{
"base_url":"http://127.0.0.1:41211/o_/wq";,
"core":"c8n_1x2_shard1_replica2",
"node_name":"127.0.0.1:41211_o_%2Fwq",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"replicationFactor":"2"},
"collection1":{
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{
"core_node1":{
"base_url":"http://127.0.0.1:41211/o_/wq";,
"core":"collection1",
"node_name":"127.0.0.1:41211_o_%2Fwq",
"state":"active",
"leader":"true"},
"core_node3":{
"base_url":"http://127.0.0.1:40576/o_/wq";,
"core":"collection1",
"node_name":"127.0.0.1:40576_o_%2Fwq",
"state":"active"}}},
"shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{"core_node2":{
"base_url":"http://127.0.0.1:43415/o_/wq";,
"core":"collection1",
"node_name":"127.0.0.1:43415_o_%2Fwq",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true",
"replicationFactor":"1"},
"control_collection":{
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"base_url":"http://127.0.0.1:46370/o_/wq";,
"core":"collection1",
"node_name":"127.0.0.1:46370_o_%2Fwq",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true",
"replicationFactor":"1"}}
at
__randomizedtesting.SeedInfo.seed([47D2483C1DE5BF5B:CF8677E6B3
[jira] [Commented] (SOLR-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699281#comment-14699281 ] Jan Høydahl commented on SOLR-7920: --- Not my intention either to sneak this into the ongoing release. Now that it is there, as an extra verification I checked out and built the 5.3 branch, and manually verified that the schema browser works as expected, and that the xss is fixed. But of course, RM [~noble.paul] has the final word and the power to revert. > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699250#comment-14699250 ] Uwe Schindler commented on SOLR-7920: - If Noble prepares a respin with that one, just move changes entries. If we don't release that in 5.3.0, you have to move the lucene_solr_5_3 branch, away from 5.3.0. For now I would set "Fix verson" to "5.3", too. > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699230#comment-14699230 ] Upayavira commented on SOLR-7920: - [~thetaphi] yes, I thought of that after doing it. I can revert - although, it is such a small change, in which case, the only fix required is to move the comment from the 5.4 section to the 5.3 one. Thoughts? > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699223#comment-14699223 ] Uwe Schindler commented on SOLR-7920: - The new 5.3 snapshots were not yet created, but you commited to 5.3, so it should appear on 5.3.0 after respin of RC? > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699198#comment-14699198 ] Upayavira commented on SOLR-7920: - [~janhoy] Done. However, there was no 5.3.1 section in CHANGES.txt, so I added it to the 5.4.0 section in that branch. I presume we'll fix that should 5.3.1 ever see the light of day. > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699193#comment-14699193 ] ASF subversion and git services commented on SOLR-7920: --- Commit 1696217 from [~upayavira] in branch 'dev/trunk' [ https://svn.apache.org/r1696217 ] SOLR-7920: Update CHANGES.txt > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699187#comment-14699187 ] ASF subversion and git services commented on SOLR-7920: --- Commit 1696213 from [~upayavira] in branch 'dev/branches/lucene_solr_5_3' [ https://svn.apache.org/r1696213 ] SOLR-7920: Resolve XSS issue in old Schema Browser admin UI pane > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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-7920) Thers is a xss issue in schema-browser page of Admin Web UI.
[ https://issues.apache.org/jira/browse/SOLR-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699190#comment-14699190 ] ASF subversion and git services commented on SOLR-7920: --- Commit 1696215 from [~upayavira] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1696215 ] SOLR-7920: Update CHANGES.txt > Thers is a xss issue in schema-browser page of Admin Web UI. > > > Key: SOLR-7920 > URL: https://issues.apache.org/jira/browse/SOLR-7920 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.9, 4.10.4, 5.2.1 >Reporter: davidchiu >Assignee: Upayavira > Fix For: 5.4 > > > Open Solr Admin Web UI, select a core(such as collection1) and then click > "schema-browse",and input a url like > "http://127.0.0.1:8983/solr/#/collection1/schema-browser?field=cat= onerror=alert(1);>" to the browser address, you will get alert box with "1". > I changed follow code to void this problem: > Original code: > $( 'option[value="' + params.route_params.path + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); > Changed code: > $( 'option[value="' + params.route_params.path.esc() + '"]', > related_select_element ) > .attr( 'selected', 'selected' ); -- 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
