[ https://issues.apache.org/jira/browse/SOLR-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337836#comment-17337836 ]
Ilan Ginzburg edited comment on SOLR-15146 at 5/1/21, 4:29 PM: --------------------------------------------------------------- [~mdrob] I see this test failing in a similar way earlier than April 17th. It doesn't seem related to my changes. If you think otherwise, can you please share more context? In old repo March 7 this year: ??Build: [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/29630/]?? ??Java: 64bit/jdk-13.0.2 -XX:-UseCompressedOops -XX:+UseParallelGC?? ??2 tests failed.?? ??FAILED: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream?? ??Error Message:?? ??java.lang.AssertionError: expected:<8> but was:<4>?? ??Stack Trace:?? ??java.lang.AssertionError: expected:<8> but was:<4>?? ?? at __randomizedtesting.SeedInfo.seed([568BE78267F4F618:66F0565158B488BF]:0)?? ?? at org.junit.Assert.fail(Assert.java:89)?? ?? at org.junit.Assert.failNotEquals(Assert.java:835)?? ?? at org.junit.Assert.assertEquals(Assert.java:647)?? ?? at org.junit.Assert.assertEquals(Assert.java:633)?? ?? at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream(StreamDecoratorTest.java:2648)?? ?? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)?? In new repo April 7: ??Build: [https://jenkins.thetaphi.de/job/Solr-main-Linux/233/]?? ??Java: 64bit/jdk-11.0.6 -XX:-UseCompressedOops -XX:+UseParallelGC?? ??3 tests failed.?? ??FAILED: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream?? ??Error Message:?? ??java.lang.AssertionError: expected:<5> but was:<4>?? ??Stack Trace:?? ??java.lang.AssertionError: expected:<5> but was:<4>?? ?? at __randomizedtesting.SeedInfo.seed([A613324F91DBC694:9668839CAE9BB833]:0)?? ?? at org.junit.Assert.fail(Assert.java:89)?? ?? at org.junit.Assert.failNotEquals(Assert.java:835)?? ?? at org.junit.Assert.assertEquals(Assert.java:647)?? ?? at org.junit.Assert.assertEquals(Assert.java:633)?? ?? at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream(StreamDecoratorTest.java:2648)?? ?? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)?? was (Author: murblanc): [~mdrob] I see this test failing in a similar way earlier than April 17th. It doesn't seem related to my changes. If you think otherwise, can you please share more context? In old repo March 7 this year: ??Build: [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/29630/]?? ??Java: 64bit/jdk-13.0.2 -XX:-UseCompressedOops -XX:+UseParallelGC?? ??2 tests failed.?? ??FAILED: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream?? ??Error Message:?? ??java.lang.AssertionError: expected:<8> but was:<4>?? ??Stack Trace:?? ??java.lang.AssertionError: expected:<8> but was:<4>?? ?? at __randomizedtesting.SeedInfo.seed([568BE78267F4F618:66F0565158B488BF]:0)?? ?? at org.junit.Assert.fail(Assert.java:89)?? ?? at org.junit.Assert.failNotEquals(Assert.java:835)?? ?? at org.junit.Assert.assertEquals(Assert.java:647)?? ?? at org.junit.Assert.assertEquals(Assert.java:633)?? ?? at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream(StreamDecoratorTest.java:2648)?? ?? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)?? In new repo: ??Build: [https://jenkins.thetaphi.de/job/Solr-main-Linux/233/]?? ??Java: 64bit/jdk-11.0.6 -XX:-UseCompressedOops -XX:+UseParallelGC?? ??3 tests failed.?? ??FAILED: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream?? ??Error Message:?? ??java.lang.AssertionError: expected:<5> but was:<4>?? ??Stack Trace:?? ??java.lang.AssertionError: expected:<5> but was:<4>?? ?? at __randomizedtesting.SeedInfo.seed([A613324F91DBC694:9668839CAE9BB833]:0)?? ?? at org.junit.Assert.fail(Assert.java:89)?? ?? at org.junit.Assert.failNotEquals(Assert.java:835)?? ?? at org.junit.Assert.assertEquals(Assert.java:647)?? ?? at org.junit.Assert.assertEquals(Assert.java:633)?? ?? at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelPriorityStream(StreamDecoratorTest.java:2648)?? ?? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)?? > Distribute Collection API command execution > ------------------------------------------- > > Key: SOLR-15146 > URL: https://issues.apache.org/jira/browse/SOLR-15146 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud > Affects Versions: main (9.0) > Reporter: Ilan Ginzburg > Assignee: Ilan Ginzburg > Priority: Major > Labels: collection-api, overseer > Time Spent: 40m > Remaining Estimate: 0h > > Building on the distributed cluster state update changes (SOLR-14928), this > ticket will distribute the Collection API so that commands can execute on any > node (i.e. the node handling the request through {{CollectionsHandler}}) > without having to go through a Zookeeper queue and the Overseer. > This is the second step (first was SOLR-14928) after which the Overseer > could be removed (but the code keeps existing execution options so completion > by no means Overseer is gone, but it could be removed in a future release). > -There is a dependency on the distributed cluster state changes because the > Overseer locking protecting same collection (or same shard) Collection API > commands from executing concurrently will be replaced by optimistic locking > of the collection {{state.json}} znodes (or other znodes that will eventually > replace/augment {{state.json}}).- > The goal of this ticket is threefold: > * Simplify the code (running synchronously and not going through the > Zookeeper queues and the Overseer dequeue logic is much simpler), > * Lead to improved performance for most/all use cases (although this is a > secondary goal, as long as performance is not degraded) and > * Allow a future change (in another future Jira) to the way cluster state is > cached on the nodes of the cluster (keep less information, be less dependent > on Zookeeper watches, do not care about collections not present on the node). > This future work will aim to significantly increase the scale (amount of > collections) supported by SolrCloud. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org