[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 607 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/607/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI Error Message: Error from server at https://127.0.0.1:43073/solr/awhollynewcollection_0_shard3_replica_n4: ClusterState says we are the leader (https://127.0.0.1:43073/solr/awhollynewcollection_0_shard3_replica_n4), but locally we don't think so. Request came from null Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:43073/solr/awhollynewcollection_0_shard3_replica_n4: ClusterState says we are the leader (https://127.0.0.1:43073/solr/awhollynewcollection_0_shard3_replica_n4), but locally we don't think so. Request came from null at __randomizedtesting.SeedInfo.seed([D20747C58601919D:9A7233718032BE08]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:459) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Statement
[jira] [Commented] (LUCENE-4100) Maxscore - Efficient Scoring
[ https://issues.apache.org/jira/browse/LUCENE-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203051#comment-16203051 ] Robert Muir commented on LUCENE-4100: - Can we avoid the ScoreMode.merge? This seems really, really confusing. In general I don't think we should support such merging in MultiCollector or anywhere else, we should simply throw exception if things are different. I think the enum should be further revisited/simplified: essentially at the minimum it must capture 2 booleans from the user: whether scores are needed, and whether exact total hit count is needed. Perhaps instead of the enum two booleans would be easier for now. I don't understand why we should set the totalHitCount to -1, vs setting to a useful approximation, like google. The user said they didn't need the exact total hit count, so it should be no surprise, and its a hell of a lot more useful than a negative number. > Maxscore - Efficient Scoring > > > Key: LUCENE-4100 > URL: https://issues.apache.org/jira/browse/LUCENE-4100 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs, core/query/scoring, core/search >Affects Versions: 4.0-ALPHA >Reporter: Stefan Pohl > Labels: api-change, gsoc2014, patch, performance > Fix For: 4.9, 6.0 > > Attachments: LUCENE-4100.patch, LUCENE-4100.patch, > contrib_maxscore.tgz, maxscore.patch > > > At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient > algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood, > that I find deserves more attention among Lucene users (and developers). > I implemented a proof of concept and did some performance measurements with > example queries and lucenebench, the package of Mike McCandless, resulting in > very significant speedups. > This ticket is to get started the discussion on including the implementation > into Lucene's codebase. Because the technique requires awareness about it > from the Lucene user/developer, it seems best to become a contrib/module > package so that it consciously can be chosen to be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 606 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/606/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=17287, name=jetty-launcher-2946-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=17287, name=jetty-launcher-2946-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) at __randomizedtesting.SeedInfo.seed([F5F67A40B9C4CA76]:0) Build Log: [...truncated 13373 lines...] [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation [junit4] 2> 2159021 INFO (SUITE-TestSolrCloudWithSecureImpersonation-seed#[F5F67A40B9C4CA76]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_F5F67A40B9C4CA76-001/init-core-data-001 [junit4] 2> 2159022 INFO (SUITE-TestSolrCloudWithSecureImpersonation-seed#[F5F67A40B9C4CA76]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 2159023 INFO (SUITE-TestSolrCloudWithSecureImpersonation-seed#[F5F67A40B9C4CA76]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
[jira] [Updated] (SOLR-11467) CdcrBootstrapTest::testBootstrapWithContinousIndexingOnSourceCluster Failure
[
https://issues.apache.org/jira/browse/SOLR-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11467:
-
Affects Version/s: (was: master (8.0))
7.1
6.6
6.6.1
7.0
7.0.1
> CdcrBootstrapTest::testBootstrapWithContinousIndexingOnSourceCluster Failure
>
>
> Key: SOLR-11467
> URL: https://issues.apache.org/jira/browse/SOLR-11467
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
>Affects Versions: 6.6, 6.6.1, 7.0, 7.0.1, 7.1
>Reporter: Amrit Sarkar
> Attachments: SOLR-11467-debug-code.log
>
>
> CdcrBootstrapTest is still failing in master and other branches with:
> {code}
> [junit4] FAILURE 130s J1 |
> CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Document mismatch on
> target after sync expected:<2000> but was:<1901>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([41753A7BCCA7C778:953071222BF17483]:0)
>[junit4]> at
> org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> {code}
> ref: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/423/
> From one of the failed Solr jenkins log:
>[junit4] 2> 1143166 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 991 updates
> to target cdcr-target
>[junit4] 2> 1144176 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 909 updates
> to target cdcr-target
>[junit4] 2> 1145118 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 0 updates
> to target cdcr-target
> Total 1900 updates were sent, instead of 2000. Ideally the bootstrap process
> is responsible for 1000, and normal cdc replication is responsble for 1000.
> On looking closely, the bootstrap is completed successfully. We are 100% sure
> here, bootstrap worked w/o any issue. And still 1900 updates were sent via
> replicator, instead of 1000.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11467) CdcrBootstrapTest::testBootstrapWithContinousIndexingOnSourceCluster Failure
[
https://issues.apache.org/jira/browse/SOLR-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203024#comment-16203024
]
Varun Thacker commented on SOLR-11467:
--
Hi Amrit,
I'll commit the patch with additional logging shortly.
Making a couple of changes before committing :
This probably doesn't need to change?
{code}
- System.out.println("Adding " + docs + " docs with commit=true, numDocs=" +
numDocs);
+ System.out.println("Adding 100 docs with commit=true, numDocs=" + numDocs);
{code}
Adding "nocommit" will get precommit. So removing that comment and adding
another placeholder
> CdcrBootstrapTest::testBootstrapWithContinousIndexingOnSourceCluster Failure
>
>
> Key: SOLR-11467
> URL: https://issues.apache.org/jira/browse/SOLR-11467
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
>Affects Versions: 6.6, 6.6.1, 7.0, 7.0.1, 7.1
>Reporter: Amrit Sarkar
> Attachments: SOLR-11467-debug-code.log
>
>
> CdcrBootstrapTest is still failing in master and other branches with:
> {code}
> [junit4] FAILURE 130s J1 |
> CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Document mismatch on
> target after sync expected:<2000> but was:<1901>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([41753A7BCCA7C778:953071222BF17483]:0)
>[junit4]> at
> org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> {code}
> ref: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/423/
> From one of the failed Solr jenkins log:
>[junit4] 2> 1143166 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 991 updates
> to target cdcr-target
>[junit4] 2> 1144176 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 909 updates
> to target cdcr-target
>[junit4] 2> 1145118 INFO
> (cdcr-replicator-4421-thread-1-processing-n:127.0.0.1:62832_solr
> x:cdcr-source_shard1_replica_n1 s:shard1 c:cdcr-source r:core_node2)
> [n:127.0.0.1:62832_solr c:cdcr-source s:shard1 r:core_node2
> x:cdcr-source_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 0 updates
> to target cdcr-target
> Total 1900 updates were sent, instead of 2000. Ideally the bootstrap process
> is responsible for 1000, and normal cdc replication is responsble for 1000.
> On looking closely, the bootstrap is completed successfully. We are 100% sure
> here, bootstrap worked w/o any issue. And still 1900 updates were sent via
> replicator, instead of 1000.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.1 - Build # 1 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.1/1/ No tests ran. Build Log: [...truncated 28184 lines...] ERROR: command execution failed. ERROR: lucene is offline; cannot locate JDK 1.8 (latest) Email was triggered for: Failure - Any Sending email for trigger: Failure - Any ERROR: lucene is offline; cannot locate JDK 1.8 (latest) ERROR: lucene is offline; cannot locate JDK 1.8 (latest) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11392) StreamExpressionTest.testParallelExecutorStream fails too frequently
[
https://issues.apache.org/jira/browse/SOLR-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203010#comment-16203010
]
Shalin Shekhar Mangar commented on SOLR-11392:
--
bq. Notice this is looking for the "_n3" replica. What's odd about this is that
only two replicas where created for this collection
Joel, sorry for the late reply. Solr does not create replica numbers
sequentially anymore. This was done in SOLR-11011
> StreamExpressionTest.testParallelExecutorStream fails too frequently
>
>
> Key: SOLR-11392
> URL: https://issues.apache.org/jira/browse/SOLR-11392
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>
> I've never been able to reproduce the failure but jenkins fails frequently
> with the following error:
> {code}
> Stack Trace:
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
> server at http://127.0.0.1:38180/solr/workQueue_shard2_replica_n3: Expected
> mime type application/octet-stream but got text/html.
>
>
> Error 404
>
>
> HTTP ERROR: 404
> Problem accessing /solr/workQueue_shard2_replica_n3/update. Reason:
> Can not find: /solr/workQueue_shard2_replica_n3/update
> http://eclipse.org/jetty";>Powered by Jetty://
> 9.3.20.v20170531
>
>
> {code}
> What appears to be happening is that the test framework is having trouble
> setting up the collection.
> Here is the test code:
> {code}
> @Test
> public void testParallelExecutorStream() throws Exception {
> CollectionAdminRequest.createCollection("workQueue", "conf", 2,
> 1).process(cluster.getSolrClient());
> AbstractDistribZkTestBase.waitForRecoveriesToFinish("workQueue",
> cluster.getSolrClient().getZkStateReader(),
> false, true, TIMEOUT);
> CollectionAdminRequest.createCollection("mainCorpus", "conf", 2,
> 1).process(cluster.getSolrClient());
> AbstractDistribZkTestBase.waitForRecoveriesToFinish("mainCorpus",
> cluster.getSolrClient().getZkStateReader(),
> false, true, TIMEOUT);
> CollectionAdminRequest.createCollection("destination", "conf", 2,
> 1).process(cluster.getSolrClient());
> AbstractDistribZkTestBase.waitForRecoveriesToFinish("destination",
> cluster.getSolrClient().getZkStateReader(),
> false, true, TIMEOUT);
> UpdateRequest workRequest = new UpdateRequest();
> UpdateRequest dataRequest = new UpdateRequest();
> for (int i = 0; i < 500; i++) {
> workRequest.add(id, String.valueOf(i), "expr_s", "update(destination,
> batchSize=50, search(mainCorpus, q=id:"+i+", rows=1, sort=\"id asc\",
> fl=\"id, body_t, field_i\"))");
> dataRequest.add(id, String.valueOf(i), "body_t", "hello world "+i,
> "field_i", Integer.toString(i));
> }
> workRequest.commit(cluster.getSolrClient(), "workQueue");
> dataRequest.commit(cluster.getSolrClient(), "mainCorpus");
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203007#comment-16203007 ] Varun Thacker commented on SOLR-8389: - bq. ZkStateReader keeps a set of watchers for each of them (one per collection), in a similar way to state.json. But on top of caching the values, it provides a method where you can add listeners, that will be called each time the znode is changed. Will it suffer from the same problem as putting the configs in state.json? Unrelated updates in the collection properties api might trigger a bootstrap ? > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11485) Add olsRegress, olsPredict and olsResiduals Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-11485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-11485: -- Fix Version/s: master (8.0) 7.2 > Add olsRegress, olsPredict and olsResiduals Stream Evaluators > - > > Key: SOLR-11485 > URL: https://issues.apache.org/jira/browse/SOLR-11485 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Fix For: 7.2, master (8.0) > > > This ticket adds support for OLS (ordinary least squares) multiple > regression, prediction and residuals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11485) Add olsRegress, olsPredict and olsResiduals Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-11485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein reassigned SOLR-11485: - Assignee: Joel Bernstein > Add olsRegress, olsPredict and olsResiduals Stream Evaluators > - > > Key: SOLR-11485 > URL: https://issues.apache.org/jira/browse/SOLR-11485 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Fix For: 7.2, master (8.0) > > > This ticket adds support for OLS (ordinary least squares) multiple > regression, prediction and residuals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11485) Add olsRegress, olsPredict and olsResiduals Stream Evaluators
Joel Bernstein created SOLR-11485: - Summary: Add olsRegress, olsPredict and olsResiduals Stream Evaluators Key: SOLR-11485 URL: https://issues.apache.org/jira/browse/SOLR-11485 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein This ticket adds support for OLS (ordinary least squares) multiple regression, prediction and residuals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-11445.
-
Resolution: Fixed
Assignee: Cao Manh Dat
Fix Version/s: master (8.0)
7.2
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202914#comment-16202914
]
ASF subversion and git services commented on SOLR-11445:
Commit fc981dd5acee6962ff1d35e8238af4e47829e4b5 in lucene-solr's branch
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fc981dd ]
SOLR-11445: Overseer should not hang when process bad message
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202915#comment-16202915
]
ASF subversion and git services commented on SOLR-11445:
Commit 2795287b0e56148102ae802259a59d80907e4d1a in lucene-solr's branch
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2795287 ]
SOLR-11445: Upgrade CHANGES.txt
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202912#comment-16202912
]
ASF subversion and git services commented on SOLR-11445:
Commit 4bc7fd2bd54c6a06f88c9aa2de9d3b94f5a77efb in lucene-solr's branch
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4bc7fd2 ]
SOLR-11445: Upgrade CHANGES.txt
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11484) Possible bug with CloudSolrClient directedUpdates & cached collection state -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
[
https://issues.apache.org/jira/browse/SOLR-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202881#comment-16202881
]
Joel Bernstein edited comment on SOLR-11484 at 10/13/17 12:50 AM:
--
[~hossman], [~noble.paul], this is related I believe to SOLR-11392.
[~romseygeek], discusses the issue in the ticket.
was (Author: joel.bernstein):
[~hossman], [~noble.paul], this is related I believe: SOLR-11392.
[~romseygeek], discusses the issue in the ticket.
> Possible bug with CloudSolrClient directedUpdates & cached collection state
> -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
> -
>
> Key: SOLR-11484
> URL: https://issues.apache.org/jira/browse/SOLR-11484
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.20662.txt
>
>
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}}
> seems to fail with non-trivial frequency, so I grabbed the logs from a recent
> failure and starting trying to follow along with the actions to figure out
> what exactly is happening
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
> {noformat}
>[junit4] ERROR 20.3s J1 |
> TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
> server at https://127.0.0.1:42959/solr/testcollection_shard1_replica_n3:
> Expected mime type a
> pplication/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=ISO-8859-1"/>
>[junit4]> Error 404
> {noformat}
> The crux of this failure appears to be a genuine bug in how CloudSolrClient
> uses it's cached ClusterState info when doing (direct) updates. The key bits
> seem to be:
> * CloudSolrClient does _something_ (update,query,etc...) with a collection
> causing the current cluster state for the collection to be cached
> * The actual collection changes such that a Solr node/core no longer exists
> as part of the collection
> * CloudSolrClient is asked to process an UpdateRequest which triggers the
> code paths for the {{directUpdate()}} method -- which attempts to route the
> updates directly to a replica of the appropriate shard using the (cache)
> collection state info
> * CloudSolrClient (may) attempt to send that UpdateRequest to a node/core
> that doesn't exist, getting a 404 -- which does not (seem to) trigger a state
> refresh, or retry to find a correct URL to resend the update to.
> Details to follow in comment
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11484) Possible bug with CloudSolrClient directedUpdates & cached collection state -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
[
https://issues.apache.org/jira/browse/SOLR-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202881#comment-16202881
]
Joel Bernstein commented on SOLR-11484:
---
[~hossman], [~noble.paul], this is related I believe: SOLR-11392.
[~romseygeek], discusses the issue in the ticket.
> Possible bug with CloudSolrClient directedUpdates & cached collection state
> -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
> -
>
> Key: SOLR-11484
> URL: https://issues.apache.org/jira/browse/SOLR-11484
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: jenkins.thetaphi.20662.txt
>
>
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}}
> seems to fail with non-trivial frequency, so I grabbed the logs from a recent
> failure and starting trying to follow along with the actions to figure out
> what exactly is happening
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
> {noformat}
>[junit4] ERROR 20.3s J1 |
> TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
>[junit4]> Throwable #1:
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
> server at https://127.0.0.1:42959/solr/testcollection_shard1_replica_n3:
> Expected mime type a
> pplication/octet-stream but got text/html.
>[junit4]>
>[junit4]> content="text/html;charset=ISO-8859-1"/>
>[junit4]> Error 404
> {noformat}
> The crux of this failure appears to be a genuine bug in how CloudSolrClient
> uses it's cached ClusterState info when doing (direct) updates. The key bits
> seem to be:
> * CloudSolrClient does _something_ (update,query,etc...) with a collection
> causing the current cluster state for the collection to be cached
> * The actual collection changes such that a Solr node/core no longer exists
> as part of the collection
> * CloudSolrClient is asked to process an UpdateRequest which triggers the
> code paths for the {{directUpdate()}} method -- which attempts to route the
> updates directly to a replica of the appropriate shard using the (cache)
> collection state info
> * CloudSolrClient (may) attempt to send that UpdateRequest to a node/core
> that doesn't exist, getting a 404 -- which does not (seem to) trigger a state
> refresh, or retry to find a correct URL to resend the update to.
> Details to follow in comment
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11484) Possible bug with CloudSolrClient directedUpdates & cached collection state -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
[
https://issues.apache.org/jira/browse/SOLR-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-11484:
Attachment: jenkins.thetaphi.20662.txt
I've attached the log from
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
A quick walk through of some of the key bits of logging from
testCollectionCreateSearchDelete ...
Test Creates a 2x2 collection, resulting in 4 SolrCores...
{noformat}
[junit4] 2> 334246 INFO
(parallelCoreAdminExecutor-1592-thread-1-processing-n:127.0.0.1:42959_solr
aecb57e9-be15-41b4-892b-269c3ef4df623724636310642455 CREATE)
[n:127.0.0.1:42959_solr] o.a.s.h.a.CoreAdminOperation core create command
qt=/admin/cores&collection.configName=solrCloudCollectionConfig&newCollection=true&collection=testcollection&version=2&replicaType=NRT&async=aecb57e9-be15-41b4-892b-269c3ef4df623724636310642455&coreNodeName=core_node4&name=testcollection_shard1_replica_n3&action=CREATE&numShards=2&shard=shard1&property.solr.directoryFactory=solr.StandardDirectoryFactory&wt=javabin
[junit4] 2> 334261 INFO
(parallelCoreAdminExecutor-1581-thread-1-processing-n:127.0.0.1:34827_solr
aecb57e9-be15-41b4-892b-269c3ef4df623724636321671098 CREATE)
[n:127.0.0.1:34827_solr] o.a.s.h.a.CoreAdminOperation core create command
qt=/admin/cores&collection.configName=solrCloudCollectionConfig&newCollection=true&collection=testcollection&version=2&replicaType=NRT&async=aecb57e9-be15-41b4-892b-269c3ef4df623724636321671098&coreNodeName=core_node8&name=testcollection_shard2_replica_n6&action=CREATE&numShards=2&shard=shard2&property.solr.directoryFactory=solr.StandardDirectoryFactory&wt=javabin
[junit4] 2> 334272 INFO
(parallelCoreAdminExecutor-1579-thread-1-processing-n:127.0.0.1:38927_solr
aecb57e9-be15-41b4-892b-269c3ef4df623724636317202530 CREATE)
[n:127.0.0.1:38927_solr] o.a.s.h.a.CoreAdminOperation core create command
qt=/admin/cores&collection.configName=solrCloudCollectionConfig&newCollection=true&collection=testcollection&version=2&replicaType=NRT&async=aecb57e9-be15-41b4-892b-269c3ef4df623724636317202530&coreNodeName=core_node7&name=testcollection_shard2_replica_n5&action=CREATE&numShards=2&shard=shard2&property.solr.directoryFactory=solr.StandardDirectoryFactory&wt=javabin
[junit4] 2> 334272 INFO
(parallelCoreAdminExecutor-1577-thread-1-processing-n:127.0.0.1:36233_solr
aecb57e9-be15-41b4-892b-269c3ef4df623724636304239736 CREATE)
[n:127.0.0.1:36233_solr] o.a.s.h.a.CoreAdminOperation core create command
qt=/admin/cores&collection.configName=solrCloudCollectionConfig&newCollection=true&collection=testcollection&version=2&replicaType=NRT&async=aecb57e9-be15-41b4-892b-269c3ef4df623724636304239736&coreNodeName=core_node2&name=testcollection_shard1_replica_n1&action=CREATE&numShards=2&shard=shard1&property.solr.directoryFactory=solr.StandardDirectoryFactory&wt=javabin
{noformat}
Note that these initial Cores are:
* testcollection_shard1_replica_n3
* testcollection_shard2_replica_n6
* testcollection_shard2_replica_n5
* testcollection_shard1_replica_n1
...the test then does some searching of this collection, and a few other
things, before ultimately deleting this collection, and verifies the delete
worked correctly...
{noformat}
[junit4] 2> 340530 INFO
(TEST-TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete-seed#[DC2FFDE51D1E4138])
[] o.a.s.c.AbstractDistribZkTestBase Wait for collection to disappear -
collection: testcollection failOnTimeout:true timeout (sec):330
[junit4] 1> -
[junit4] 2> 340530 INFO
(TEST-TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete-seed#[DC2FFDE51D1E4138])
[] o.a.s.c.AbstractDistribZkTestBase Collection has disappeared -
collection: testcollection
{noformat}
...at which point it recreates the collection, and we get 4 completely new
SolrCores...
{noformat}
[junit4] 2> 340531 INFO (qtp6784903-4183) [n:127.0.0.1:38927_solr]
o.a.s.h.a.CollectionsHandler Invoked Collection Action :create with params
replicationFactor=2&collection.configName=solrCloudCollectionConfig&maxShardsPerNode=1&name=testcollection&nrtReplicas=2&action=CREATE&numShards=2&property.solr.directoryFactory=solr.StandardDirectoryFactory&wt=javabin&version=2
and sendToOCPQueue=true
[junit4] 2> 340533 INFO
(OverseerThreadFactory-1587-thread-3-processing-n:127.0.0.1:34827_solr)
[n:127.0.0.1:34827_solr] o.a.s.c.CreateCollectionCmd Create collection
testcollection
[junit4] 2> 340948 INFO (qtp13197426-4184) [n:127.0.0.1:36233_solr]
o.a.s.h.a.CoreAdminOperation core create command
qt=/admin/cores&collection.configName=solrCloudCollectionConfig&newCollection=true&collection=testcollection&version=2&replicaType=NRT&coreNodeName=core_node8&name=testcollection_shard2_replica_n6&action=CREATE&numShards=2&shard=shard2&property.solr.directoryFactory=solr.StandardDi
[jira] [Created] (SOLR-11484) Possible bug with CloudSolrClient directedUpdates & cached collection state -- TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
Hoss Man created SOLR-11484:
---
Summary: Possible bug with CloudSolrClient directedUpdates &
cached collection state --
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
Key: SOLR-11484
URL: https://issues.apache.org/jira/browse/SOLR-11484
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
{{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}}
seems to fail with non-trivial frequency, so I grabbed the logs from a recent
failure and starting trying to follow along with the actions to figure out what
exactly is happening
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
{noformat}
[junit4] ERROR 20.3s J1 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at https://127.0.0.1:42959/solr/testcollection_shard1_replica_n3:
Expected mime type a
pplication/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404
{noformat}
The crux of this failure appears to be a genuine bug in how CloudSolrClient
uses it's cached ClusterState info when doing (direct) updates. The key bits
seem to be:
* CloudSolrClient does _something_ (update,query,etc...) with a collection
causing the current cluster state for the collection to be cached
* The actual collection changes such that a Solr node/core no longer exists as
part of the collection
* CloudSolrClient is asked to process an UpdateRequest which triggers the code
paths for the {{directUpdate()}} method -- which attempts to route the updates
directly to a replica of the appropriate shard using the (cache) collection
state info
* CloudSolrClient (may) attempt to send that UpdateRequest to a node/core that
doesn't exist, getting a 404 -- which does not (seem to) trigger a state
refresh, or retry to find a correct URL to resend the update to.
Details to follow in comment
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1401 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1401/ 8 tests failed. FAILED: org.apache.solr.cloud.TestLocalFSCloudBackupRestore.test Error Message: expected: but was: Stack Trace: java.lang.AssertionError: expected: but was: at __randomizedtesting.SeedInfo.seed([317B471B1312A108:B92F78C1BDEECCF0]: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.cloud.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:277) at org.apache.solr.cloud.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TriLevelCompositeIdRoutingTest Error Message: 1
[jira] [Commented] (SOLR-11481) Ref guide page explaining nuances of the recovery process
[ https://issues.apache.org/jira/browse/SOLR-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202739#comment-16202739 ] Varun Thacker commented on SOLR-11481: -- We document the params in http://lucene.apache.org/solr/guide/updatehandlers-in-solrconfig.html#transaction-log but it doesn't explain how they interplay > Ref guide page explaining nuances of the recovery process > - > > Key: SOLR-11481 > URL: https://issues.apache.org/jira/browse/SOLR-11481 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > > The Solr recovery process involves PeerSync , which has configuration > parameters to allow the number of records it should keep. > If this fails we do a index replication where possibly we can throttle > replication > I think it's worth explaining to users what these configuration parameters > are and how does a node actually recover. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11483) Keep more transaction log files when maxNumLogsToKeep is specified
Varun Thacker created SOLR-11483: Summary: Keep more transaction log files when maxNumLogsToKeep is specified Key: SOLR-11483 URL: https://issues.apache.org/jira/browse/SOLR-11483 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Varun Thacker We allow users to control the number of transaction log files the system should keep ( maxNumLogsToKeep ) and the number of records to keep ( numRecordsToKeep ) However just by setting numRecordsToKeep we are not guaranteed that the system will actually keep that many records. This comment explains why - https://issues.apache.org/jira/browse/SOLR-6359?focusedCommentId=15214361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15214361 A tradeoff would be if a user explicitly specifies numRecordsToKeep and doesn't specify maxNumLogsToKeep then we should use a higher default for maxNumLogsToKeep ( say 1000 instead of 10 today ) Off course better documentation will help so if others think this is a bad idea then we can close this out and just make sure it's documented and if users know about one parameter they will know about the other parameter as well -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11481) Ref guide page explaining nuances of the recovery process
[
https://issues.apache.org/jira/browse/SOLR-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202731#comment-16202731
]
Varun Thacker commented on SOLR-11481:
--
{code}
${solr.ulog.dir:}
1
{code}
One might assume that if he sets numRecordsToKeep that PeerSync will actually
try to sync upto these many records. But looking at the code we only keep 10
transaction log files by default even when when this number is set.
Yonik explains on SOLR-6359 that this is because we don't want to run out of
file handles in the corner case of add 1 doc + commit , add 1 doc + commit
case.
So we also need to add specify maxNumLogsToKeep and keep it to a high number as
well .
Honestly my first reaction is that to accommodate users who are explicitly
specifying a high numRecordsToKeep and then doing commits after every add we
are choosing trappy behaviour for the remaining 99% users is a bad tradeoff.
I'll file a separate Jira to see where that goes.
So for PeerSync we need to document both maxNumLogsToKeep and numRecordsToKeep
and how they help improve recovery times.
> Ref guide page explaining nuances of the recovery process
> -
>
> Key: SOLR-11481
> URL: https://issues.apache.org/jira/browse/SOLR-11481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Minor
>
> The Solr recovery process involves PeerSync , which has configuration
> parameters to allow the number of records it should keep.
> If this fails we do a index replication where possibly we can throttle
> replication
> I think it's worth explaining to users what these configuration parameters
> are and how does a node actually recover.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error
[
https://issues.apache.org/jira/browse/LUCENE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202705#comment-16202705
]
Michael McCandless edited comment on LUCENE-7538 at 10/12/17 10:14 PM:
---
[~ashah301182] see {{IndexWriter.MAX_STORED_STRING_LENGTH}} for the limit;
you'll have to either not store that huge file, or break it up across several
documents.
was (Author: mikemccand):
[~nkeet] see {{IndexWriter.MAX_STORED_STRING_LENGTH}} for the limit; you'll
have to either not store that huge file, or break it up across several
documents.
> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a
> large text file to a single Solr text field. The field definition in the
> schema.xml is:
> {noformat}
> termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until
> we reloaded the Solr core. The text file had size of 800MB, containing only
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR
> org.apache.solr.handler.RequestHandlerBase -
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1
> to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
> at
> org.apache.tomcat.util.
[jira] [Comment Edited] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error
[
https://issues.apache.org/jira/browse/LUCENE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202705#comment-16202705
]
Michael McCandless edited comment on LUCENE-7538 at 10/12/17 10:13 PM:
---
[~nkeet] see {{IndexWriter.MAX_STORED_STRING_LENGTH}} for the limit; you'll
have to either not store that huge file, or break it up across several
documents.
was (Author: mikemccand):
@nkeet see {{IndexWriter.MAX_STORED_STRING_LENGTH}} for the limit; you'll have
to either not store that huge file, or break it up across several documents.
> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a
> large text file to a single Solr text field. The field definition in the
> schema.xml is:
> {noformat}
> termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until
> we reloaded the Solr core. The text file had size of 800MB, containing only
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR
> org.apache.solr.handler.RequestHandlerBase -
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1
> to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
> at
> org.apache.tomcat.util.net.NioEn
[jira] [Commented] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error
[
https://issues.apache.org/jira/browse/LUCENE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202707#comment-16202707
]
Erick Erickson commented on LUCENE-7538:
There are probably some a-priori limits, somewhere someplace lots of data has
to be kept. The document has to be indexed in memory-resident segments
(essentially) before being flushed. I question whether it's reasonable to even
try to index documents this large.
>From a user's perspective, what's the value in indexing such a huge document?
>Assuming it's text, it's quite likely that it'll be found for almost every
>search... and have such a low score that it won't be seen by the users. It
>can't be displayed in a browser, it's too big. Even transmitting it to the
>client is prohibitive.
So I'd ask a little different question: "What's the largest document it makes
sense to index?". Personally I think it's far, far less than a gigabyte
> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a
> large text file to a single Solr text field. The field definition in the
> schema.xml is:
> {noformat}
> termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until
> we reloaded the Solr core. The text file had size of 800MB, containing only
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR
> org.apache.solr.handler.RequestHandlerBase -
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1
> to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>
[jira] [Commented] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error
[
https://issues.apache.org/jira/browse/LUCENE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202705#comment-16202705
]
Michael McCandless commented on LUCENE-7538:
@nkeet see {{IndexWriter.MAX_STORED_STRING_LENGTH}} for the limit; you'll have
to either not store that huge file, or break it up across several documents.
> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a
> large text file to a single Solr text field. The field definition in the
> schema.xml is:
> {noformat}
> termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until
> we reloaded the Solr core. The text file had size of 800MB, containing only
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR
> org.apache.solr.handler.RequestHandlerBase -
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1
> to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1
[jira] [Updated] (SOLR-11481) Ref guide page explaining nuances of the recovery process
[ https://issues.apache.org/jira/browse/SOLR-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11481: - Priority: Minor (was: Major) > Ref guide page explaining nuances of the recovery process > - > > Key: SOLR-11481 > URL: https://issues.apache.org/jira/browse/SOLR-11481 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > > The Solr recovery process involves PeerSync , which has configuration > parameters to allow the number of records it should keep. > If this fails we do a index replication where possibly we can throttle > replication > I think it's worth explaining to users what these configuration parameters > are and how does a node actually recover. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11481) Ref guide page explaining nuances of the recovery process
Varun Thacker created SOLR-11481: Summary: Ref guide page explaining nuances of the recovery process Key: SOLR-11481 URL: https://issues.apache.org/jira/browse/SOLR-11481 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Varun Thacker The Solr recovery process involves PeerSync , which has configuration parameters to allow the number of records it should keep. If this fails we do a index replication where possibly we can throttle replication I think it's worth explaining to users what these configuration parameters are and how does a node actually recover. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error
[
https://issues.apache.org/jira/browse/LUCENE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202681#comment-16202681
]
nkeet commented on LUCENE-7538:
---
Thanks for having this fixed. I have been using SOLR 6.1.0 for just about a
year now, and i recently stated seeing this issue. On ivestigation, i found
that, at times i have files which are 1GB huge. Now i do unsterstand that this
fix will prevent the IndexWriter from closing. but how do you index such a huge
file, are we saying that there is a limit to the file size that can be
indexed?, if yes what is the limit?
> Uploading large text file to a field causes "this IndexWriter is closed" error
> --
>
> Key: LUCENE-7538
> URL: https://issues.apache.org/jira/browse/LUCENE-7538
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 5.5.1
>Reporter: Steve Chen
> Fix For: 6.4, 7.0
>
> Attachments: LUCENE-7538.patch, LUCENE-7538.patch
>
>
> We have seen "this IndexWriter is closed" error after we tried to upload a
> large text file to a single Solr text field. The field definition in the
> schema.xml is:
> {noformat}
> termVectors="true" termPositions="true" termOffsets="true"/>
> {noformat}
> After that, the IndexWriter remained closed and couldn't be recovered until
> we reloaded the Solr core. The text file had size of 800MB, containing only
> numbers and English characters.
> Stack trace is shown below:
> {noformat}
> 2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR
> org.apache.solr.handler.RequestHandlerBase -
> org.apache.solr.common.SolrException: Exception writing document id 1487_0_1
> to the index; possible analysis error.
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
> at
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
> at
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at
> veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
> at
> org.apache.tomcat.util.net.NioEnd
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20665 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20665/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.OverseerRolesTest.testOverseerRole Error Message: Timed out waiting for overseer state change Stack Trace: java.lang.AssertionError: Timed out waiting for overseer state change at __randomizedtesting.SeedInfo.seed([99A71852907370ED:786CE5C6ABC0463C]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:62) at org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:140) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13222 lines...] [junit4] Suite: org.apache.solr.cloud.OverseerRolesTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.Overse
[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections
[ https://issues.apache.org/jira/browse/SOLR-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202597#comment-16202597 ] ASF subversion and git services commented on SOLR-11469: Commit 75498a6132ecd6c9afc01b8f12722eebf9b764df in lucene-solr's branch refs/heads/branch_7x from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=75498a6 ] SOLR-11469: disable LeaderElectionContextKeyTest since we know it's logically flawed (cherry picked from commit cd1a635898e2d37b723ae648a270242f9fc80323) > LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the > wrong shard's elections > > > Key: SOLR-11469 > URL: https://issues.apache.org/jira/browse/SOLR-11469 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-11469.patch, SOLR-11469_incomplete_and_broken.patch > > > LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports > it shows a suspiciously close to "50%" failure rate. > Digging into the test i realized that it creates a 2 shard index, then picks > "a leader" to kill (arbitrarily) and then asserts that the leader election > nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 > leader and then fails because it doesn't see an election in shard1. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections
[ https://issues.apache.org/jira/browse/SOLR-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202598#comment-16202598 ] ASF subversion and git services commented on SOLR-11469: Commit cd1a635898e2d37b723ae648a270242f9fc80323 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cd1a635 ] SOLR-11469: disable LeaderElectionContextKeyTest since we know it's logically flawed > LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the > wrong shard's elections > > > Key: SOLR-11469 > URL: https://issues.apache.org/jira/browse/SOLR-11469 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-11469.patch, SOLR-11469_incomplete_and_broken.patch > > > LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports > it shows a suspiciously close to "50%" failure rate. > Digging into the test i realized that it creates a 2 shard index, then picks > "a leader" to kill (arbitrarily) and then asserts that the leader election > nodes for *shard1* are affected ... so ~50% of the time it kills the shard2 > leader and then fails because it doesn't see an election in shard1. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11450) ComplexPhraseQParserPlugin not running charfilter for some multiterm queries in 6.x
[ https://issues.apache.org/jira/browse/SOLR-11450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202585#comment-16202585 ] Tim Allison commented on SOLR-11450: To get the directionality right...sorry. The issue I opened is a duplicate of LUCENE-7687...my error. > ComplexPhraseQParserPlugin not running charfilter for some multiterm queries > in 6.x > > > Key: SOLR-11450 > URL: https://issues.apache.org/jira/browse/SOLR-11450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Tim Allison >Priority: Minor > Attachments: SOLR-11450-unit-test.patch, SOLR-11450.patch > > > On the user list, [~bjarkebm] reported that the charfilter is not being > applied in PrefixQueries in the ComplexPhraseQParserPlugin in 6.x. Bjarke > fixed my proposed unit tests to prove this failure. All appears to work in > 7.x and trunk. If there are plans to release a 6.6.2, let's fold this in. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11450) ComplexPhraseQParserPlugin not running charfilter for some multiterm queries in 6.x
[ https://issues.apache.org/jira/browse/SOLR-11450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202573#comment-16202573 ] Tim Allison commented on SOLR-11450: [~mikemccand] [~jpountz], any chance you'd be willing to review and push this into 6.6.2? > ComplexPhraseQParserPlugin not running charfilter for some multiterm queries > in 6.x > > > Key: SOLR-11450 > URL: https://issues.apache.org/jira/browse/SOLR-11450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Tim Allison >Priority: Minor > Attachments: SOLR-11450-unit-test.patch, SOLR-11450.patch > > > On the user list, [~bjarkebm] reported that the charfilter is not being > applied in PrefixQueries in the ComplexPhraseQParserPlugin in 6.x. Bjarke > fixed my proposed unit tests to prove this failure. All appears to work in > 7.x and trunk. If there are plans to release a 6.6.2, let's fold this in. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11480) Remove lingering admin-extra.html files and references
[ https://issues.apache.org/jira/browse/SOLR-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-11480: - Attachment: SOLR-11480.patch Here is a patch version, however there is some new lines etc that showed up that aren't in the GitHub PR version... argh. > Remove lingering admin-extra.html files and references > -- > > Key: SOLR-11480 > URL: https://issues.apache.org/jira/browse/SOLR-11480 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, examples >Affects Versions: 6.6 >Reporter: Eric Pugh >Priority: Minor > Attachments: SOLR-11480.patch > > > There are still some admin-extra related files, most confusingly, in the > techproducts configset! I started up solr with -e techproducts, and saw the > files listed, but couldn't use them. > While sad to see it go, I think it's better to have it be completely removed, > versus still lingering about. > Related to https://issues.apache.org/jira/browse/SOLR-8140. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7687) ComplexPhraseQueryParser with AsciiFoldingFilterFactory (SOLR)
[
https://issues.apache.org/jira/browse/LUCENE-7687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202561#comment-16202561
]
Tim Allison commented on LUCENE-7687:
-
There's a patch available on SOLR-11450. This seems to have been fixed in 7.x
> ComplexPhraseQueryParser with AsciiFoldingFilterFactory (SOLR)
> --
>
> Key: LUCENE-7687
> URL: https://issues.apache.org/jira/browse/LUCENE-7687
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.4.1
> Environment: solr-6.4.1 (yes, solr, but I don't know where the bug
> exactly is)
>Reporter: Jochen Barth
>
> I modified generic *_txt-Field type to use AsciiFoldingFilterFactory on query
> & index.
> When quering with
> \{!complexphrase}text_txt:"König*" -- there are 0 results
> \{!complexphrase}text_txt:"Konig*" -- there are >0 results
> \{!complexphrase}text_txt:"König" -- there are >0 results (but less than the
> line above)
> and without \{!complexphrase} everything works o.k.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11480) Remove lingering admin-extra.html files and references
Eric Pugh created SOLR-11480: Summary: Remove lingering admin-extra.html files and references Key: SOLR-11480 URL: https://issues.apache.org/jira/browse/SOLR-11480 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI, examples Affects Versions: 6.6 Reporter: Eric Pugh Priority: Minor There are still some admin-extra related files, most confusingly, in the techproducts configset! I started up solr with -e techproducts, and saw the files listed, but couldn't use them. While sad to see it go, I think it's better to have it be completely removed, versus still lingering about. Related to https://issues.apache.org/jira/browse/SOLR-8140. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #261: Cleanup admin extra
GitHub user epugh opened a pull request: https://github.com/apache/lucene-solr/pull/261 Cleanup admin extra You can merge this pull request into a Git repository by running: $ git pull https://github.com/epugh/lucene-solr cleanup_admin_extra Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/261.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #261 commit 2fd6e25986b81c914f3972f5de9211fe4e272447 Author: epugh Date: 2017-10-12T19:50:50Z remove from list of gettable files the no longer used admin-extra.html commit 1cfc7525348663057aeb86fce7fc7fe10b63889e Author: epugh Date: 2017-10-12T19:50:50Z Revert "remove from list of gettable files the no longer used admin-extra.html" This reverts commit 2fd6e25986b81c914f3972f5de9211fe4e272447. commit e8bd7dc966f30e6fffb8adeb471c01b6cddc04b7 Author: epugh Date: 2017-10-12T20:00:30Z remove deprecated admin-extra.html from list of gettable files commit 6f78fc67e8c008efb587e2995e798c2cdbcd4792 Author: epugh Date: 2017-10-12T20:02:50Z removed now deprecated admin files from example configurations. commit fabf60501465c79571112b18ed0672b4c9966c05 Author: epugh Date: 2017-10-12T20:04:20Z remove no longer used admin files from -e techproducts demo --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 603 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/603/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication Error Message: Index: 0, Size: 0 Stack Trace: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at __randomizedtesting.SeedInfo.seed([65E8B336A3F734D0:71A0E86380F089CE]:0) at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication(TestReplicationHandler.java:561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12240 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> 730155 INFO (SUITE-TestReplicationHandler-seed#[65E8B336A3F734D0]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allow
[jira] [Commented] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
[
https://issues.apache.org/jira/browse/SOLR-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202400#comment-16202400
]
Hoss Man commented on SOLR-11479:
-
discovered while trying to fix the tests in SOLR-11469
> Collections API: ADDREPLICA fails if you try to specify
> property.coreNodeName=foo
> -
>
> Key: SOLR-11479
> URL: https://issues.apache.org/jira/browse/SOLR-11479
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11479.patch
>
>
> if you attempt to specify a {{property.coreNodeName}} param when using the
> Collection API's {{action=ADDREPLICA}} the request will fail -- the
> underlying cause of the failure (in the logs for the node where the
> underlying Core Admin CREATECORE request is routed) seems like a perplexing
> chicken/egg problem...
> (the various names in the error below are from a test patch i'll attach
> shortly)
> {noformat}
>[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
> create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
>[junit4] 2> ... 34 more
>[junit4] 2> Caused by: org.apache.solr.common.SolrException:
> coreNodeName user_assigned_node_name does not exist in shard shard1:
> DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
> ...
>[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
> c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
> x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/cores
> params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
> status=400 QTime=3009
> {noformat}
> ...the CREATE core action is failing because the cloud shard we want to
> ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11469) LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the wrong shard's elections
[
https://issues.apache.org/jira/browse/SOLR-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-11469:
Attachment: SOLR-11469_incomplete_and_broken.patch
bq. I'm not really sure how to make this test work reliably? ... unless maybe
we manually add replicas with explicitly specified coreNodeName and force them
to be the leader
FWIW, the attached {{SOLR-11469_incomplete_and_broken.patch}} attempts this,
but i ran into SOLR-11479 which currently makes this impossible.
> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the
> wrong shard's elections
>
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11469.patch, SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks
> "a leader" to kill (arbitrarily) and then asserts that the leader election
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2
> leader and then fails because it doesn't see an election in shard1.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
[
https://issues.apache.org/jira/browse/SOLR-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-11479:
Attachment: SOLR-11479.patch
here's a (test only) patch demonstrating the problem ... really straight
forward addition to CollectionsAPISolrJTest...
{code}
@Test
public void testAddReplicaWithCoreNodeNameProp() throws Exception {
final String collectionName = "solrj_replica_explicit_coreNodeName";
CollectionAdminRequest.createCollection(collectionName, "conf", 1, 2)
.process(cluster.getSolrClient());
final String coreNodeName = "user_assigned_node_name";
CollectionAdminResponse response =
CollectionAdminRequest.addReplicaToShard(collectionName, "shard1")
.withProperty(CoreDescriptor.CORE_NODE_NAME, coreNodeName)
.process(cluster.getSolrClient());
assertEquals(0, response.getStatus());
assertTrue(response.isSuccess());
Replica newReplica = grabNewReplica(response,
getCollectionState(collectionName));
assertTrue(newReplica.getName().equals(coreNodeName));
}
{code}
> Collections API: ADDREPLICA fails if you try to specify
> property.coreNodeName=foo
> -
>
> Key: SOLR-11479
> URL: https://issues.apache.org/jira/browse/SOLR-11479
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-11479.patch
>
>
> if you attempt to specify a {{property.coreNodeName}} param when using the
> Collection API's {{action=ADDREPLICA}} the request will fail -- the
> underlying cause of the failure (in the logs for the node where the
> underlying Core Admin CREATECORE request is routed) seems like a perplexing
> chicken/egg problem...
> (the various names in the error below are from a test patch i'll attach
> shortly)
> {noformat}
>[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
> create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
>[junit4] 2> at
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
>[junit4] 2> ... 34 more
>[junit4] 2> Caused by: org.apache.solr.common.SolrException:
> coreNodeName user_assigned_node_name does not exist in shard shard1:
> DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
> ...
>[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
> c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
> x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/cores
> params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
> status=400 QTime=3009
> {noformat}
> ...the CREATE core action is failing because the cloud shard we want to
> ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11479) Collections API: ADDREPLICA fails if you try to specify property.coreNodeName=foo
Hoss Man created SOLR-11479:
---
Summary: Collections API: ADDREPLICA fails if you try to specify
property.coreNodeName=foo
Key: SOLR-11479
URL: https://issues.apache.org/jira/browse/SOLR-11479
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
if you attempt to specify a {{property.coreNodeName}} param when using the
Collection API's {{action=ADDREPLICA}} the request will fail -- the underlying
cause of the failure (in the logs for the node where the underlying Core Admin
CREATECORE request is routed) seems like a perplexing chicken/egg problem...
(the various names in the error below are from a test patch i'll attach shortly)
{noformat}
[junit4] 2> Caused by: org.apache.solr.common.SolrException: Unable to
create core [solrj_replica_explicit_coreNodeName_shard1_replica_n5]
[junit4] 2>at
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1049)
[junit4] 2>at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:947)
[junit4] 2>... 34 more
[junit4] 2> Caused by: org.apache.solr.common.SolrException: coreNodeName
user_assigned_node_name does not exist in shard shard1:
DocCollection(solrj_replica_explicit_coreNodeName//collections/solrj_replica_explicit_coreNodeName/state.json/7)={
...
[junit4] 2> 11157 INFO (qtp1977346252-47) [n:127.0.0.1:51786_solr
c:solrj_replica_explicit_coreNodeName s:shard1 r:user_assigned_node_name
x:solrj_replica_explicit_coreNodeName_shard1_replica_n5] o.a.s.s.HttpSolrCall
[admin] webapp=null path=/admin/cores
params={qt=/admin/cores&coreNodeName=core_node6&collection.configName=conf&name=solrj_replica_explicit_coreNodeName_shard1_replica_n5&property.coreNodeName=user_assigned_node_name&action=CREATE&collection=solrj_replica_explicit_coreNodeName&shard=shard1&wt=javabin&version=2&replicaType=NRT}
status=400 QTime=3009
{noformat}
...the CREATE core action is failing because the cloud shard we want to
ADDREPLICA to says that a replica with that coreNodeName doesn't exist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11478) Solr should remove it's entry from live_nodes in zk immediately on shutdown and add after solr has loaded it's cores and is ready to serve requests.
Binoy Dalal created SOLR-11478: -- Summary: Solr should remove it's entry from live_nodes in zk immediately on shutdown and add after solr has loaded it's cores and is ready to serve requests. Key: SOLR-11478 URL: https://issues.apache.org/jira/browse/SOLR-11478 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Binoy Dalal Priority: Minor Solr currently, upon receiving the stop command, removes its entry from the zk /live_nodes znode after it has finished processing all inflight requests, just before finally shutting down. In this case, any applications that depend on a solr node's live_node entry to decide whether or not to query it fail once the stop command has been executed but solr has not yet fully shut down. Something similar occurs during startup of a solr node. The solr node seems to add it's entry to the /live_nodes in zk once it is up but before it has started accepting requests and once again, this causes dependent applications to fail in a similar fashion. Hence, removal of the node entry and addition of the same to the zk live_nodes immediately upon shutting down and at the very end upon coming up respectively will greatly benefit applications that depend the live_nodes znode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4222 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4222/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC --illegal-access=deny 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample Error Message: ObjectTracker found 5 object(s) that were not released!!! [TransactionLog, MDCAwareThreadPoolExecutor, NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.TransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.TransactionLog.(TransactionLog.java:190) at org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:448) at org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1261) at org.apache.solr.update.UpdateLog.add(UpdateLog.java:534) at org.apache.solr.update.UpdateLog.add(UpdateLog.java:519) at org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:352) at org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:271) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:221) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:991) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1207) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:753) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:474) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91) at org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98) at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:188) at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:144) at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:311) at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256) at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:130) at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:276) at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256) at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:178) at org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:195) at org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108) at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55) at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequ
[jira] [Commented] (SOLR-11452) TestTlogReplica.testOnlyLeaderIndexes() failure
[
https://issues.apache.org/jira/browse/SOLR-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202253#comment-16202253
]
Hoss Man commented on SOLR-11452:
-
Dat: we're still seeing jenkins failures (even on master) from these asserts...
https://builds.apache.org/job/Lucene-Solr-Tests-master/2119/
{noformat}
expected:<1> but was:<0>
Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at
__randomizedtesting.SeedInfo.seed([1F0F4531096B9C4:1DF189DE6533C757]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.solr.cloud.TestTlogReplica.assertCopyOverOldUpdates(TestTlogReplica.java:916)
at
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:490)
{noformat}
> TestTlogReplica.testOnlyLeaderIndexes() failure
> ---
>
> Key: SOLR-11452
> URL: https://issues.apache.org/jira/browse/SOLR-11452
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>
> Reproduces for me, from
> [https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1398]:
> {noformat}
> Checking out Revision f0a4b2dafe13e2b372e33ce13d552f169187a44e
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestTlogReplica
> -Dtests.method=testOnlyLeaderIndexes -Dtests.seed=CCAC87827208491B
> -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
> -Dtests.locale=el -Dtests.timezone=Australia/LHI -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 29.5s J2 | TestTlogReplica.testOnlyLeaderIndexes <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
> was:<5>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([CCAC87827208491B:D0ADFA0F07AD3788]:0)
>[junit4]> at
> org.apache.solr.cloud.TestTlogReplica.assertCopyOverOldUpdates(TestTlogReplica.java:909)
>[junit4]> at
> org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:501)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=CheapBastard,
> sim=RandomSimilarity(queryNorm=false): {}, locale=el, timezone=Australia/LHI
>[junit4] 2> NOTE: Linux 3.13.0-88-generic amd64/Oracle Corporation
> 1.8.0_144 (64-bit)/cpus=4,threads=1,free=137513712,total=520093696
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 246 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/246/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.LeaderElectionContextKeyTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([3684889586F2CF57:BED0B74F280EA2AF]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.LeaderElectionContextKeyTest.test(LeaderElectionContextKeyTest.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling Error Message: Both triggers should have fired by now Stack Trace: java.lang.AssertionError: Both triggers should have fired by now at __randomizedtesting.SeedInfo.seed([3684889586F2CF57:CDA620B054582CC5]:0)
[jira] [Updated] (LUCENE-4100) Maxscore - Efficient Scoring
[ https://issues.apache.org/jira/browse/LUCENE-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4100: - Attachment: LUCENE-4100.patch Here is a patch: - more docs and tests - replaces needsScores with a SearchMode enum as suggested by Robert - the MAXSCORE optimization work with top-level disjunctions and filtered disjunctions (FILTER or MUST_NOT) - TopScoreDocsCollector sets the totalHitCount to -1 when the optimization is used since the total hit count is unknown - MaxScoreScorer was changed to reason on integers rather than doubles to avoid floating-point arithmetic issues. To do that it scales all max scores into 0..2^16, rounding up when working on the max scores of sub clauses, and down when rounding the min competitive score in order to make sure to not miss matches (at the cost of potentially more false positives, but this is fine) The patch is alreay huge (due to the needsScore/searchMode change mostly) so I wanted to do the strict minimum here for this feature to be useful, but we'll need follow-ups to make the optimization work with the paging collector, conjunctions that have more than one scoring clause, TopFieldCollector when the first sort field is the score, integrate it with IndexSearcher (currently you need to create the collector manually to use it), etc. > Maxscore - Efficient Scoring > > > Key: LUCENE-4100 > URL: https://issues.apache.org/jira/browse/LUCENE-4100 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs, core/query/scoring, core/search >Affects Versions: 4.0-ALPHA >Reporter: Stefan Pohl > Labels: api-change, gsoc2014, patch, performance > Fix For: 4.9, 6.0 > > Attachments: LUCENE-4100.patch, LUCENE-4100.patch, > contrib_maxscore.tgz, maxscore.patch > > > At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient > algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood, > that I find deserves more attention among Lucene users (and developers). > I implemented a proof of concept and did some performance measurements with > example queries and lucenebench, the package of Mike McCandless, resulting in > very significant speedups. > This ticket is to get started the discussion on including the implementation > into Lucene's codebase. Because the technique requires awareness about it > from the Lucene user/developer, it seems best to become a contrib/module > package so that it consciously can be chosen to be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-7992) Kuromoji fails with UnsupportedOperationException in case of duplicate keys in the user dictionary
[ https://issues.apache.org/jira/browse/LUCENE-7992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Moen reassigned LUCENE-7992: -- Assignee: Christian Moen > Kuromoji fails with UnsupportedOperationException in case of duplicate keys > in the user dictionary > -- > > Key: LUCENE-7992 > URL: https://issues.apache.org/jira/browse/LUCENE-7992 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Assignee: Christian Moen >Priority: Minor > > Failing is the right thing to do but the exception could clarify the source > of the problem. Today it just throws an UnsupportedOperationException with no > error message because of a call to PositiveIntOutputs.merge. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7992) Kuromoji fails with UnsupportedOperationException in case of duplicate keys in the user dictionary
[ https://issues.apache.org/jira/browse/LUCENE-7992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202098#comment-16202098 ] Christian Moen commented on LUCENE-7992: Thanks, Adrien. I'll have a look. > Kuromoji fails with UnsupportedOperationException in case of duplicate keys > in the user dictionary > -- > > Key: LUCENE-7992 > URL: https://issues.apache.org/jira/browse/LUCENE-7992 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > > Failing is the right thing to do but the exception could clarify the source > of the problem. Today it just throws an UnsupportedOperationException with no > error message because of a call to PositiveIntOutputs.merge. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7992) Kuromoji fails with UnsupportedOperationException in case of duplicate keys in the user dictionary
Adrien Grand created LUCENE-7992: Summary: Kuromoji fails with UnsupportedOperationException in case of duplicate keys in the user dictionary Key: LUCENE-7992 URL: https://issues.apache.org/jira/browse/LUCENE-7992 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Priority: Minor Failing is the right thing to do but the exception could clarify the source of the problem. Today it just throws an UnsupportedOperationException with no error message because of a call to PositiveIntOutputs.merge. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9) - Build # 20663 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20663/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC --illegal-access=deny 1 tests failed. FAILED: org.apache.solr.cloud.LeaderElectionContextKeyTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E5E30D1D8F479F6C:6DB732C721BBF294]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.LeaderElectionContextKeyTest.test(LeaderElectionContextKeyTest.java:88) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 13266 lines...] [junit4] Suite: org.apache.solr.cloud.LeaderElectionContextKeyTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.LeaderElectionContextKeyTest_E5E30D1D8F479F6C-001/init-core-data
[JENKINS] Lucene-Solr-Tests-master - Build # 2119 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2119/ 5 tests failed. FAILED: org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([1F0F4531096B9C4:1DF189DE6533C757]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.TestTlogReplica.assertCopyOverOldUpdates(TestTlogReplica.java:916) at org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:490) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.core.snapshots.TestSolrCloudSnapshots.testSnapshots Error Message: Coul
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_144) - Build # 6956 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6956/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrIndexConfig Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001 at __randomizedtesting.SeedInfo.seed([8C6FF671EFE9C986]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11946 lines...] [junit4] Suite: org.apache.solr.core.TestSolrIndexConfig [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.core.TestSolrIndexConfig_8C6FF671EFE9C986-001\init-core-data-001 [junit4] 2> 533159 WARN (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=10 numCloses=10 [junit4] 2> 533159 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 533163 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN) [junit4] 2> 533163 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 533164 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 533164 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/C:/Users/jenkins/workspace/Lucene-Solr-master-Windows/solr/core/src/test-files/solr/collection1/lib, /C:/Users/jenkins/workspace/Lucene-Solr-master-Windows/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 533191 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.u.SolrIndexConfig IndexWriter infoStream solr logging is enabled [junit4] 2> 533191 INFO (SUITE-TestSolrIndexConfig-seed#[8C6FF671EFE9C986]-worker) [] o.a.s.c.SolrConfig Using
Making "routing" strategies for writing segments explicit ?
Hi all, having been involved in such kind of challenge and having seen a few more similar enquiries on the dev list, I was wondering if it may be time to think about making it possible to have an explicit (customizable and therefore pluggable) policy which allows people to chime into where documents and / or segments get written (on write or on merge). Recently there was someone asking about possibly having segments sorted by a field using SortingMergePolicy, but as Uwe noted it's currently an implementation detail. Personally I have tried (and failed because it was too costly) to make sure docs belonging to certain clusters (identified by a field) being written within same segments (for data locality / memory footprint concerns when "loading" docs from a certain cluster). As of today that'd be *really* hard, but I just wanted to share my feeling that such topic might be something to keep an eye on. My 2 cents, Tommaso
[jira] [Resolved] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-11451.
---
Resolution: Fixed
Fix Version/s: 7.2
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 7.2
>
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201968#comment-16201968
]
ASF subversion and git services commented on SOLR-11451:
Commit d3ef1bff41e781ad077ff0dbf314c4ed8e33f80f in lucene-solr's branch
refs/heads/branch_7_1 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3ef1bf ]
SOLR-11451: ComputePlanActionTest.testNodeLost() failure
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 7.2
>
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201967#comment-16201967
]
ASF subversion and git services commented on SOLR-11451:
Commit 2345b087bcd0840ae491fabc01a9cbf669e0a29b in lucene-solr's branch
refs/heads/branch_7_1 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2345b08 ]
SOLR-11451: added logging to track the failures
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 7.2
>
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201958#comment-16201958
]
ASF subversion and git services commented on SOLR-11451:
Commit 3f3e49d5bc9ab8603386d8544640661bb0a5b2ab in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3f3e49d ]
SOLR-11451: ComputePlanActionTest.testNodeLost() failure
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201957#comment-16201957
]
ASF subversion and git services commented on SOLR-11451:
Commit c969634b6bd9fc8d73d95ff1a1e9169a26efa38c in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c969634 ]
SOLR-11451: added logging to track the failures
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 7.1.0 RC1
+1 SUCCESS! [3:35:06.139114] Il giorno gio 12 ott 2017 alle ore 13:20 Shalin Shekhar Mangar < sha...@apache.org> ha scritto: > Please vote for release candidate 1 for Lucene/Solr 7.1.0 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.1.0-RC1-reva2c54447f118a5dc70ab0e0ae14bd87b3545254b > > 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-7.1.0-RC1-reva2c54447f118a5dc70ab0e0ae14bd87b3545254b > > Smoke tester passed for me (but on the 2nd attempt due to a flaky test > that's already being tracked in a Jira). > SUCCESS! [0:55:14.107386] > > Here's my +1 to release. > > > -- > 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-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201949#comment-16201949
]
ASF subversion and git services commented on SOLR-11451:
Commit 4f52d2db109557c5e6ddf2b6f0bdf7090707f41b in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f52d2d ]
SOLR-11451: ComputePlanActionTest.testNodeLost() failure
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 601 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/601/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 4 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=13291, name=jetty-launcher-1531-thread-1-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=13288, name=jetty-launcher-1531-thread-2-SendThread(127.0.0.1:42127), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 3) Thread[id=13289, name=jetty-launcher-1531-thread-1-SendThread(127.0.0.1:42127), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 4) Thread[id=13290, name=jetty-launcher-1531-thread-2-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 4 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=13291, name=jetty-launcher-1531-thread-1-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=13288, name=jetty-launcher-1531-thread-2-SendThread(127.0.0.1:42127), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 3) Thread[id=13289, name=jetty-launcher-1531-thread-1-SendThread(127.0.0.1:42127), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 4) Thread[id=13290, name=jetty-launcher-1531-thread-2-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) at __randomizedtesting.SeedInfo.seed([44A114FA7C211A7C]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=13288, name=jetty-launcher-1531-thread-2-SendThread(127.0.0.1:42127), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureIm
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201866#comment-16201866 ] Kevin Risden commented on SOLR-11444: - Changes for SQL sounds reasonable to me. I think streaming expressions support aliases now. When it was originally implemented not sure that was the case. > Improve Aliases.java and comma delimited collection list handling > - > > Key: SOLR-11444 > URL: https://issues.apache.org/jira/browse/SOLR-11444 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley > Attachments: SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch > > > While starting to look at SOLR-11299 I noticed some brittleness in > assumptions about Strings that refer to a collection. Sometimes they are in > fact references to comma separated lists, which appears was added with the > introduction of collection aliases (an alias can refer to a comma delimited > list). So Java's type system kind of goes out the window when we do this. > In one case this leads to a bug -- CloudSolrClient will throw an NPE if you > try to write to such an alias. Sending an update via HTTP will allow it and > send it to the first in the list. > So this issue is about refactoring and some little improvements pertaining to > Aliases.java plus certain key spots that deal with collection references. I > don't think I want to go as far as changing the public SolrJ API except to > adding documentation on what's possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11476) Solr seems to ignore replica placement rules
Franz Wimmer created SOLR-11476:
---
Summary: Solr seems to ignore replica placement rules
Key: SOLR-11476
URL: https://issues.apache.org/jira/browse/SOLR-11476
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: v2 API
Affects Versions: 7.0.1, 7.0, 6.6.1
Reporter: Franz Wimmer
I'm running Solr Cloud in OpenShift. I have set up 5 pods across the cluster,
each running one solr node. The instances are managed by a ZooKeeper ensemble.
In Solr 6.1, when I created a collection with 5 shards and a replicationFactor
of 2, it would distribute all 10 replicas evenly on the nodes. With Solr 6.6
and 7.0, the distribution is random (why would I even want to gather many
shards on one node and leave another node empty?).
I tried using "Rule-based Replica Placement", but my rules seem to be ignored.
I tried:
{code}
/solr/admin/collections?action=CREATE&name=wikipedia&numShards=5&maxShardsPerNode=2&replicationFactor=2&replica:<3,node:*&collection.configName=wikipedia
/solr/admin/collections?action=CREATE&name=wikipedia&numShards=5&maxShardsPerNode=2&replicationFactor=2&shard:*,replica:1,node:*&collection.configName=wikipedia
/solr/admin/collections?action=CREATE&name=wikipedia4&numShards=5&maxShardsPerNode=2&replicationFactor=2&replica:2,node:*&collection.configName=wikipedia
{code}
In all three cases, shards are distributed unevenly, often leaving one node
completely empty.
What seems odd is, when i try a replicationFactor of 1, it still doesn't work,
but the API response is suggesting otherwise:
{code}
{
"responseHeader":{
"status":0,
"QTime":3368},
"success":{
"solr-3.solr:8983_solr":{
"responseHeader":{
"status":0,
"QTime":1836},
"core":"wikipedia5_shard5_replica_n1"},
"solr-2.solr:8983_solr":{
"responseHeader":{
"status":0,
"QTime":1852},
"core":"wikipedia5_shard4_replica_n1"},
"solr-4.solr:8983_solr":{
"responseHeader":{
"status":0,
"QTime":1859},
"core":"wikipedia5_shard3_replica_n1"},
"solr-0.solr:8983_solr":{
"responseHeader":{
"status":0,
"QTime":1867},
"core":"wikipedia5_shard2_replica_n1"},
"solr-1.solr:8983_solr":{
"responseHeader":{
"status":0,
"QTime":1872},
"core":"wikipedia5_shard1_replica_n1"}}}
{code}
Other than the returned JSON, the collection looks like this:
!https://i.imgur.com/UwqwQ5e.png!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
[
https://issues.apache.org/jira/browse/SOLR-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201846#comment-16201846
]
Mike Drob commented on SOLR-11473:
--
bq. In general, I would prefer to use the URI class throughout
HDFSDirectoryFactory for resolving paths, but this is just my personal opinion.
IIRC I tried this once before and ran into something thorny. But I can't figure
out what it was. If you run into problems, feel free to ping me about it
[~radu0gheorghe]
> Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
> -
>
> Key: SOLR-11473
> URL: https://issues.apache.org/jira/browse/SOLR-11473
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: hdfs
>Affects Versions: 6.6.1
>Reporter: Radu Gheorghe
>Priority: Minor
>
> Not sure if it's a bug or a missing feature :) I'm trying to make Solr work
> on Alluxio, as described by [~thelabdude] in
> https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
> The problem I'm facing here is with autoAddReplicas. If I have
> replicationFactor=1 and the node with that replica dies, the node taking over
> incorrectly assigns the data directory. For example:
> before
> {code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
> after
> {code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
> The same happens for ulogDir. Apparently, this has to do with this bit from
> HDFSDirectoryFactory:
> {code} public boolean isAbsolute(String path) {
> return path.startsWith("hdfs:/");
> }{code}
> If I add "alluxio:/" in there, the paths are correct and the index is
> recovered.
> I see a few options here:
> * add "alluxio:/" to the list there
> * add a regular expression in the lines of \[a-z]*:/ I hope that's not too
> expensive, I'm not sure how often this method is called
> * don't do anything and expect alluxio to work with an "hdfs:/" path? I
> actually tried that and didn't manage to make it work
> * have a different DirectoryFactory or something else?
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20662 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC
4 tests failed.
FAILED:
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup
Error Message:
null Live Nodes: [127.0.0.1:43827_solr] Last available state:
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
"pullReplicas":"0", "replicationFactor":"1", "shards":{"shard1":{
"range":"8000-7fff", "state":"active",
"replicas":{"core_node2":{
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",
"base_url":"https://127.0.0.1:43827/solr";,
"node_name":"127.0.0.1:43827_solr", "state":"active",
"type":"NRT", "leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"1",
"tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError:
null
Live Nodes: [127.0.0.1:43827_solr]
Last available state:
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",
"base_url":"https://127.0.0.1:43827/solr";,
"node_name":"127.0.0.1:43827_solr",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([DC2FFDE51D1E4138:B07B03D0CFE08D6]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carro
[jira] [Commented] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
[
https://issues.apache.org/jira/browse/SOLR-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201829#comment-16201829
]
Uwe Schindler commented on SOLR-11473:
--
You can propose a patch, if you like! I'd use:
[https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#isAbsolute--]
I don't think this method is called too often. It is not very expensive. In
general, I would prefer to use the URI class throughout HDFSDirectoryFactory
for resolving paths, but this is just my personal opinion.
> Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
> -
>
> Key: SOLR-11473
> URL: https://issues.apache.org/jira/browse/SOLR-11473
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: hdfs
>Affects Versions: 6.6.1
>Reporter: Radu Gheorghe
>Priority: Minor
>
> Not sure if it's a bug or a missing feature :) I'm trying to make Solr work
> on Alluxio, as described by [~thelabdude] in
> https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
> The problem I'm facing here is with autoAddReplicas. If I have
> replicationFactor=1 and the node with that replica dies, the node taking over
> incorrectly assigns the data directory. For example:
> before
> {code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
> after
> {code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
> The same happens for ulogDir. Apparently, this has to do with this bit from
> HDFSDirectoryFactory:
> {code} public boolean isAbsolute(String path) {
> return path.startsWith("hdfs:/");
> }{code}
> If I add "alluxio:/" in there, the paths are correct and the index is
> recovered.
> I see a few options here:
> * add "alluxio:/" to the list there
> * add a regular expression in the lines of \[a-z]*:/ I hope that's not too
> expensive, I'm not sure how often this method is called
> * don't do anything and expect alluxio to work with an "hdfs:/" path? I
> actually tried that and didn't manage to make it work
> * have a different DirectoryFactory or something else?
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
[
https://issues.apache.org/jira/browse/SOLR-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201818#comment-16201818
]
Radu Gheorghe commented on SOLR-11473:
--
Sounds good, thanks Uwe! Should I just attach a patch with that change?
> Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
> -
>
> Key: SOLR-11473
> URL: https://issues.apache.org/jira/browse/SOLR-11473
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: hdfs
>Affects Versions: 6.6.1
>Reporter: Radu Gheorghe
>Priority: Minor
>
> Not sure if it's a bug or a missing feature :) I'm trying to make Solr work
> on Alluxio, as described by [~thelabdude] in
> https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
> The problem I'm facing here is with autoAddReplicas. If I have
> replicationFactor=1 and the node with that replica dies, the node taking over
> incorrectly assigns the data directory. For example:
> before
> {code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
> after
> {code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
> The same happens for ulogDir. Apparently, this has to do with this bit from
> HDFSDirectoryFactory:
> {code} public boolean isAbsolute(String path) {
> return path.startsWith("hdfs:/");
> }{code}
> If I add "alluxio:/" in there, the paths are correct and the index is
> recovered.
> I see a few options here:
> * add "alluxio:/" to the list there
> * add a regular expression in the lines of \[a-z]*:/ I hope that's not too
> expensive, I'm not sure how often this method is called
> * don't do anything and expect alluxio to work with an "hdfs:/" path? I
> actually tried that and didn't manage to make it work
> * have a different DirectoryFactory or something else?
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
[
https://issues.apache.org/jira/browse/SOLR-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201811#comment-16201811
]
Uwe Schindler commented on SOLR-11473:
--
I'd parse this with the URI java class. After parsing it you can use methods
like isAbsolute() and similar to check the status.
> Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
> -
>
> Key: SOLR-11473
> URL: https://issues.apache.org/jira/browse/SOLR-11473
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: hdfs
>Affects Versions: 6.6.1
>Reporter: Radu Gheorghe
>Priority: Minor
>
> Not sure if it's a bug or a missing feature :) I'm trying to make Solr work
> on Alluxio, as described by [~thelabdude] in
> https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
> The problem I'm facing here is with autoAddReplicas. If I have
> replicationFactor=1 and the node with that replica dies, the node taking over
> incorrectly assigns the data directory. For example:
> before
> {code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
> after
> {code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
> The same happens for ulogDir. Apparently, this has to do with this bit from
> HDFSDirectoryFactory:
> {code} public boolean isAbsolute(String path) {
> return path.startsWith("hdfs:/");
> }{code}
> If I add "alluxio:/" in there, the paths are correct and the index is
> recovered.
> I see a few options here:
> * add "alluxio:/" to the list there
> * add a regular expression in the lines of \[a-z]*:/ I hope that's not too
> expensive, I'm not sure how often this method is called
> * don't do anything and expect alluxio to work with an "hdfs:/" path? I
> actually tried that and didn't manage to make it work
> * have a different DirectoryFactory or something else?
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 7.1.0 RC1
Please vote for release candidate 1 for Lucene/Solr 7.1.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.1.0-RC1-reva2c54447f118a5dc70ab0e0ae14bd87b3545254b 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-7.1.0-RC1-reva2c54447f118a5dc70ab0e0ae14bd87b3545254b Smoke tester passed for me (but on the 2nd attempt due to a flaky test that's already being tracked in a Jira). SUCCESS! [0:55:14.107386] Here's my +1 to release. -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-master - Build # 2537 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-master/2537/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision d8c132129ed44d8a26e7a31064e0f36b50ba8f6c
(refs/remotes/origin/master)
Commit message: "Some details about .system trigger listener, other minor
edits."
> git config core.sparsecheckout # timeout=10
> git checkout -f d8c132129ed44d8a26e7a31064e0f36b50ba8f6c
> git rev-list bac40493174b95f6eb92aacb065e6b308b8d364c # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash
/tmp/jenkins7929466548214265962.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17 0311 3804 BB82 D39D C0E3
Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36 166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'
Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.
Upgrade Notes:
* No new notes to display.
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset wrappers
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 2 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
+ ant clean build-site build-pdf
Buildfile:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml
clean:
build-init:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copying all non template files from src ...
[copy] Copying 370 files to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copy (w/prop replacement) any template files from src...
[copy] Copying 1 file to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
-ivy-fail-disallowed-ivy-version:
ivy-fail:
ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml
resolve:
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] ERRORS
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve]
[jira] [Updated] (SOLR-11475) Endless loop and OOM in PeerSync
[
https://issues.apache.org/jira/browse/SOLR-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kudryavtsev updated SOLR-11475:
--
Description:
After problem described in SOLR-11459, I restarted cluster and got OOM on
start.
[PeerSync#handleVersionsWithRanges|https://github.com/apache/lucene-solr/blob/68bda0be421ce18811e03b229781fd6152fcc04a/solr/core/src/java/org/apache/solr/update/PeerSync.java#L539]
contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
was:
After problem described in SOLR-11459, I restarted cluster and got OOM on
start.
PeerSync#handleVersionsWithRanges contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
> Endless loop and OOM in PeerSync
>
>
> Key: SOLR-11475
> URL: https://issues.apache.org/jira/browse/SOLR-11475
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrey Kudryavtsev
>
> After problem described in SOLR-11459, I restarted cluster and got OOM on
> start.
> [PeerSync#handleVersionsWithRanges|https://github.com/apache/lucene-solr/blob/68bda0be421ce18811e03b229781fd6152fcc04a/solr/core/src/java/org/apache/solr/update/PeerSync.java#L539]
> contains this logic:
> {code}
> while (otherUpdatesIndex >= 0) {
> // we have run out of ourUpdates, pick up all the remaining versions
> from the other versions
> if (ourUpdatesIndex < 0) {
> String range = otherVersions.get(otherUpdatesIndex) + "..." +
> otherVersions.get(0);
> rangesToRequest.add(range);
> totalRequestedVersions += otherUpdatesIndex + 1;
> break;
> }
> // stop when the entries get old enough that reorders may l
[jira] [Updated] (SOLR-11475) Endless loop and OOM in PeerSync
[
https://issues.apache.org/jira/browse/SOLR-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kudryavtsev updated SOLR-11475:
--
Description:
After problem described in SOLR-11459, I restarted cluster and got OOM on
start.
[PeerSync#handleVersionsWithRanges|https://github.com/apache/lucene-solr/blob/68bda0be421ce18811e03b229781fd6152fcc04a/solr/core/src/java/org/apache/solr/update/PeerSync.java#L539]
contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will add same string again and again into
{{rangesToRequest}} until process runs out of memory.
was:
After problem described in SOLR-11459, I restarted cluster and got OOM on
start.
[PeerSync#handleVersionsWithRanges|https://github.com/apache/lucene-solr/blob/68bda0be421ce18811e03b229781fd6152fcc04a/solr/core/src/java/org/apache/solr/update/PeerSync.java#L539]
contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
> Endless loop and OOM in PeerSync
>
>
> Key: SOLR-11475
> URL: https://issues.apache.org/jira/browse/SOLR-11475
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrey Kudryavtsev
>
> After problem described in SOLR-11459, I restarted cluster and got OOM on
> start.
> [PeerSync#handleVersionsWithRanges|https://github.com/apache/lucene-solr/blob/68bda0be421ce18811e03b229781fd6152fcc04a/solr/core/src/java/org/apache/solr/update/PeerSync.java#L539]
> contains this logic:
> {code}
> while (otherUpdatesIndex >= 0) {
> // we have run out of ourUpdates, pick up all the remaining versions
> from the other versions
> if (ourUpdatesIndex < 0) {
> String range = otherVersions.get(otherUpdatesIndex) + "..." +
> otherVersions.get(0);
> rangesToRequest.add(range);
>
[jira] [Updated] (SOLR-11475) Endless loop and OOM in PeerSync
[
https://issues.apache.org/jira/browse/SOLR-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kudryavtsev updated SOLR-11475:
--
Description:
After problem described in SOLR-11459, I restarted cluster and got OOM on
start.
PeerSync#handleVersionsWithRanges contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
was:
After problem discussed in SOLR-11459, I restarted cluster and got OOM on
start.
PeerSync#handleVersionsWithRanges contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
> Endless loop and OOM in PeerSync
>
>
> Key: SOLR-11475
> URL: https://issues.apache.org/jira/browse/SOLR-11475
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrey Kudryavtsev
>
> After problem described in SOLR-11459, I restarted cluster and got OOM on
> start.
> PeerSync#handleVersionsWithRanges contains this logic:
> {code}
> while (otherUpdatesIndex >= 0) {
> // we have run out of ourUpdates, pick up all the remaining versions
> from the other versions
> if (ourUpdatesIndex < 0) {
> String range = otherVersions.get(otherUpdatesIndex) + "..." +
> otherVersions.get(0);
> rangesToRequest.add(range);
> totalRequestedVersions += otherUpdatesIndex + 1;
> break;
> }
> // stop when the entries get old enough that reorders may lead us to
> see updates we don't need
> if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
> ourLowThreshold) break;
> if (ourUpdates.get(ourUpdatesIndex).longValue() ==
> otherVersions.get(otherUpdatesIndex).longValue()) {
> ourUpdatesIndex--;
> o
[jira] [Created] (SOLR-11474) Endless loop and OOM in PeerSync
Andrey Kudryavtsev created SOLR-11474:
-
Summary: Endless loop and OOM in PeerSync
Key: SOLR-11474
URL: https://issues.apache.org/jira/browse/SOLR-11474
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrey Kudryavtsev
After problem discussed in SOLR-11459, I restarted cluster and got OOM on
start.
PeerSync#handleVersionsWithRanges contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11475) Endless loop and OOM in PeerSync
Andrey Kudryavtsev created SOLR-11475:
-
Summary: Endless loop and OOM in PeerSync
Key: SOLR-11475
URL: https://issues.apache.org/jira/browse/SOLR-11475
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andrey Kudryavtsev
After problem discussed in SOLR-11459, I restarted cluster and got OOM on
start.
PeerSync#handleVersionsWithRanges contains this logic:
{code}
while (otherUpdatesIndex >= 0) {
// we have run out of ourUpdates, pick up all the remaining versions from
the other versions
if (ourUpdatesIndex < 0) {
String range = otherVersions.get(otherUpdatesIndex) + "..." +
otherVersions.get(0);
rangesToRequest.add(range);
totalRequestedVersions += otherUpdatesIndex + 1;
break;
}
// stop when the entries get old enough that reorders may lead us to see
updates we don't need
if (!completeList && Math.abs(otherVersions.get(otherUpdatesIndex)) <
ourLowThreshold) break;
if (ourUpdates.get(ourUpdatesIndex).longValue() ==
otherVersions.get(otherUpdatesIndex).longValue()) {
ourUpdatesIndex--;
otherUpdatesIndex--;
} else if (Math.abs(ourUpdates.get(ourUpdatesIndex)) <
Math.abs(otherVersions.get(otherUpdatesIndex))) {
ourUpdatesIndex--;
} else {
long rangeStart = otherVersions.get(otherUpdatesIndex);
while ((otherUpdatesIndex < otherVersions.size())
&& (Math.abs(otherVersions.get(otherUpdatesIndex)) <
Math.abs(ourUpdates.get(ourUpdatesIndex {
otherUpdatesIndex--;
totalRequestedVersions++;
}
// construct range here
rangesToRequest.add(rangeStart + "..." +
otherVersions.get(otherUpdatesIndex + 1));
}
}
{code}
If at some point there will be
{code} ourUpdates.get(ourUpdatesIndex) = -otherVersions.get(otherUpdatesIndex)
{code}
loop will never end. It will same string again and again into
{{rangesToRequest}} until process runs out of memory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
Radu Gheorghe created SOLR-11473:
Summary: Make HDFSDirectoryFactory support other prefixes (besides
hdfs:/)
Key: SOLR-11473
URL: https://issues.apache.org/jira/browse/SOLR-11473
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: hdfs
Affects Versions: 6.6.1
Reporter: Radu Gheorghe
Priority: Minor
Not sure if it's a bug or a missing feature :) I'm trying to make Solr work on
Alluxio, as described by [~thelabdude] in
https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
The problem I'm facing here is with autoAddReplicas. If I have
replicationFactor=1 and the node with that replica dies, the node taking over
incorrectly assigns the data directory. For example:
before
{code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
after
{code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
The same happens for ulogDir. Apparently, this has to do with this bit from
HDFSDirectoryFactory:
{code} public boolean isAbsolute(String path) {
return path.startsWith("hdfs:/");
}{code}
If I add "alluxio:/" in there, the paths are correct and the index is recovered.
I see a few options here:
* add "alluxio:/" to the list there
* add a regular expression in the lines of \[a-z]*:/ I hope that's not too
expensive, I'm not sure how often this method is called
* don't do anything and expect alluxio to work with an "hdfs:/" path? I
actually tried that and didn't manage to make it work
* have a different DirectoryFactory or something else?
What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 59 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/59/ No tests ran. Build Log: [...truncated 28019 lines...] prepare-release-no-sign: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.02 sec (9.4 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.2.0-src.tgz... [smoker] 30.9 MB in 0.09 sec (337.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.2.0.tgz... [smoker] 69.5 MB in 0.21 sec (334.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.2.0.zip... [smoker] 79.9 MB in 0.25 sec (318.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.2.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6221 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.2.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6221 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.2.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 213 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (17.8 MB/sec) [smoker] check changes HTML... [smoker] download solr-7.2.0-src.tgz... [smoker] 52.6 MB in 0.16 sec (327.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.2.0.tgz... [smoker] 143.8 MB in 0.43 sec (331.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.2.0.zip... [smoker] 144.8 MB in 0.43 sec (339.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-7.2.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-7.2.0.tgz... [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8 [smoker] Creating Solr home directory /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [|] [/] [-] [\] [|] [/] [-] [\]
[jira] [Updated] (SOLR-11472) Leader election bug
[ https://issues.apache.org/jira/browse/SOLR-11472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11472: - Attachment: Console_output_of_AutoscalingHistoryHandlerTest_failure.txt > Leader election bug > --- > > Key: SOLR-11472 > URL: https://issues.apache.org/jira/browse/SOLR-11472 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1, master (8.0) >Reporter: Andrzej Bialecki > Attachments: > Console_output_of_AutoscalingHistoryHandlerTest_failure.txt > > > SOLR-11407 uncovered a bug in leader election, where the same failing node is > retried indefinitely. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11472) Leader election bug
Andrzej Bialecki created SOLR-11472: Summary: Leader election bug Key: SOLR-11472 URL: https://issues.apache.org/jira/browse/SOLR-11472 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.1, master (8.0) Reporter: Andrzej Bialecki SOLR-11407 uncovered a bug in leader election, where the same failing node is retried indefinitely. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11471) MoveReplicaSuggester should suggest to move a leader only if no other replica is available
[ https://issues.apache.org/jira/browse/SOLR-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-11471: -- Summary: MoveReplicaSuggester should suggest to move a leader only if no other replica is available (was: MoveReplicaSuggester should suggest to move a leader if no other replica is available) > MoveReplicaSuggester should suggest to move a leader only if no other replica > is available > -- > > Key: SOLR-11471 > URL: https://issues.apache.org/jira/browse/SOLR-11471 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11471) MoveReplicaSuggester should suggest to move a leader if no other replica is available
Noble Paul created SOLR-11471: - Summary: MoveReplicaSuggester should suggest to move a leader if no other replica is available Key: SOLR-11471 URL: https://issues.apache.org/jira/browse/SOLR-11471 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11451) ComputePlanActionTest.testNodeLost() failure
[
https://issues.apache.org/jira/browse/SOLR-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-11451:
-
Assignee: Noble Paul
> ComputePlanActionTest.testNodeLost() failure
>
>
> Key: SOLR-11451
> URL: https://issues.apache.org/jira/browse/SOLR-11451
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Noble Paul
>
> Reproduces 100% for me (on Linux) if I remove {{-Dtests.method=testNodeLost}}
> from the repro line, from
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6946]:
> {noformat}
> Checking out Revision e92bde1e7ece020d581638f4c59c3840bf75d183
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ComputePlanActionTest -Dtests.method=testNodeLost
> -Dtests.seed=B1DFD0131B7C99E4 -Dtests.slow=true -Dtests.locale=ja
> -Dtests.timezone=Asia/Katmandu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 8.09s J1 | ComputePlanActionTest.testNodeLost <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The operations
> computed by ComputePlanAction should not be null
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([B1DFD0131B7C99E4:ECA1EED9896FC62]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost(ComputePlanActionTest.java:193)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=491, maxMBSortInHeap=6.600294616233929,
> sim=RandomSimilarity(queryNorm=true): {}, locale=ja, timezone=Asia/Katmandu
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9) - Build # 20661 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20661/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC --illegal-access=deny 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest Error Message: SolrCore.getOpenCount()==2 Stack Trace: java.lang.RuntimeException: SolrCore.getOpenCount()==2 at __randomizedtesting.SeedInfo.seed([E5C1B423C4CDC882]:0) at org.apache.solr.util.TestHarness.close(TestHarness.java:379) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:774) at org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest Error Message: SolrCore.getOpenCount()==2 Stack Trace: java.lang.RuntimeException: SolrCore.getOpenCount()==2 at __randomizedtesting.SeedInfo.seed([E5C1B423C4CDC882]:0) at org.apache.solr.util.TestHarness.close(TestHarness.java:379) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:774) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:287) at jdk.internal.reflect.GeneratedMethodAccessor63.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 60 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/60/ 12 tests failed. FAILED: org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat.testTermsEnumVariableWidth 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([9EA1AFB6B4C0022A]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([9EA1AFB6B4C0022A]:0) FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Could not load collection from ZK: collection1 Stack Trace: org.apache.solr.common.SolrException: Could not load collection from ZK: collection1 at __randomizedtesting.SeedInfo.seed([1F7247B850B685CC:97267862FE4AE834]:0) at org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1170) at org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:690) at org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:130) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.getTotalReplicas(AbstractFullDistribZkTestBase.java:488) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:441) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:334) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.e
[jira] [Commented] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201602#comment-16201602
]
ASF subversion and git services commented on SOLR-11445:
Commit df5fefb0dbfca1783126798df9c7e303d40ace16 in lucene-solr's branch
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df5fefb ]
SOLR-11445: Overseer should not hang when process bad message
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11445) Overseer should not hang when process bad message
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-11445:
Summary: Overseer should not hang when process bad message (was:
Overseer.processQueueItem() zkStateWriter.enqueueUpdate might ideally have
a try{}catch{} around it)
> Overseer should not hang when process bad message
> -
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11445) Overseer.processQueueItem().... zkStateWriter.enqueueUpdate might ideally have a try{}catch{} around it
[
https://issues.apache.org/jira/browse/SOLR-11445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-11445:
Attachment: SOLR-11445.patch
Updated patch, including test. These are some changes
- Refactoring logic of how Overseer catching Exception
- The bad message will be polled out from the queue ( message that causes
NoNodeException || NodeExistException || Any other exceptions - except
InterruptedException and KeeperException )
- After poll out the bad message, we will continue processing workqueue
Will commit soon.
> Overseer.processQueueItem() zkStateWriter.enqueueUpdate might ideally
> have a try{}catch{} around it
>
>
> Key: SOLR-11445
> URL: https://issues.apache.org/jira/browse/SOLR-11445
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Greg Harris
> Attachments: SOLR-11445.patch, SOLR-11445.patch
>
>
> So we had the following stack trace with a customer:
> 2017-10-04 11:25:30.339 ERROR () [ ] o.a.s.c.Overseer Exception in
> Overseer main queue loop
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /collections//state.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.SolrZkClient$9.execute(SolrZkClient.java:388)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at org.apache.solr.common.cloud.SolrZkClient.create(SolrZkClient.java:388)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:235)
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:199)
> at java.lang.Thread.run(Thread.java:748)
> I want to highlight:
> at
> org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:152)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:271)
> This ends up coming from Overseer:
> while (data != null) {
> final ZkNodeProps message = ZkNodeProps.load(data);
> log.debug("processMessage: workQueueSize: {}, message = {}",
> workQueue.getStats().getQueueLength(), message);
> // force flush to ZK after each message because there is no
> fallback if workQueue items
> // are removed from workQueue but fail to be written to ZK
> *clusterState = processQueueItem(message, clusterState,
> zkStateWriter, false, null);
> workQueue.poll(); // poll-ing removes the element we got by
> peek-ing*
> data = workQueue.peek();
> }
> Note: The processQueueItem comes before the poll, therefore upon a thrown
> exception the same node/message that won't process becomes stuck. This made a
> large cluster unable to come up on it's own without deleting the problem
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
