[ 
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

Reply via email to