Re: [JENKINS] Solr » Solr-Check-main-s390x - Build # 752 - Still Unstable!
+1, albeit this is super sad to call waitForState all over the place. IMO
it's a fundamental flaw that CloudSolrClient is not 100% reliable to
interact with a collection immediately after creating it, using the same
client instance. IMO even another client should work as well -- don't see
it, double-check with the server just in case it's an eventually-consistent
issue. If we used HttpClusterStateProvider instead of ZK; this pattern
would never happen since there wouldn't even be any cached state.
On Sat, Oct 12, 2024 at 2:56 AM sanjay dutt
wrote:
> Failed for the first time in 90 days. Possible Solution: May be add
> waitForStatus in-between.
>
> CollectionsAPIDistributedZkTest#testCreateNodeSet
>
> List baseUrls = List.of(jetty1.getBaseUrl().toString(),
> jetty2.getBaseUrl().toString());
>
> CollectionAdminRequest.createCollection("nodeset_collection", "conf", 2, 1)
> .setCreateNodeSet(baseUrls.get(0) + "," + baseUrls.get(1))
> .process(cluster.getSolrClient());
> DocCollection collectionState = getCollectionState("nodeset_collection");
> // Fails here
>
>
>
>
> On Sat, Oct 12, 2024 at 11:55 AM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > Build:
> > https://ci-builds.apache.org/job/Solr/job/Solr-Check-main-s390x/752/
> >
> > 1 tests failed.
> > FAILED:
> >
> org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCreateNodeSet
> >
> > Error Message:
> > org.apache.solr.common.SolrException: Could not find collection :
> > nodeset_collection
> >
> > Stack Trace:
> > org.apache.solr.common.SolrException: Could not find collection :
> > nodeset_collection
> > at
> > __randomizedtesting.SeedInfo.seed([4889AEBDFE1B2880:132A795D979A0C08]:0)
> > at
> >
> app//org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:125)
> > at
> >
> app//org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:160)
> > at
> >
> app//org.apache.solr.cloud.api.collections.AbstractCollectionsAPIDistributedZkTestBase.testCreateNodeSet(AbstractCollectionsAPIDistributedZkTestBase.java:378)
> > at java.base@11.0.24
> /jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at java.base@11.0.24
> >
> /jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at java.base@11.0.24
> >
> /jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.base@11.0.24
> > /java.lang.reflect.Method.invoke(Method.java:566)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:946)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:982)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
> > at
> >
> app//com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:80)
> > at app//org.junit.rules.RunRules.evaluate(RunRules.java:20)
> > at
> >
> app//org.apache.lucene.tests.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:48)
> > at
> >
> app//org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> > at
> >
> app//org.apache.lucene.tests.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:45)
> > at
> >
> app//org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> > at
> >
> app//org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> > at app//org.junit.rules.RunRules.evaluate(RunRules.java:20)
> > at
> >
> app//com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > at
> >
> app//com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390)
> > at
> >
> app//com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:843)
> > at
> >
> app//com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:490)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:955)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:840)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:891)
> > at
> >
> app//com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:902)
> > at
> >
> app//com.carrotsearch.randomizedtesting.rules.S
Re: Web Socket?
Just a general question to us all -- do we want to create bespoke interfaces for lifecycle or maybe embrace something else? Like Jetty's or maybe HK2 (used by Jersey)? Not sure if this quite makes sense; I haven't thought through the practicalities. On Sat, Oct 12, 2024 at 11:07 PM Gus Heck wrote: > I was traveling, and most of my ongoing work is back on my desktop, so I > entertained myself on a flight by fiddling with an idea that's been > rattling around in the back of my head. It seems like it might be neat to > have a websocket interface to solr, but we definitely don't need it to live > in the main code base since most folks will not use it, so a module seemed > appropriate. > > However, I had to do a bit of work to allow a module to start up a > socket, since the current infrastructure (as far as I could tell) only adds > to the classpath. (Possibly I missed something, feel free to point it out) > Although one *could* add an element to solr.xml to start it, it seems > pointless to force the user to declare the module AND edit a config file to > do the thing they will always have to do (start a web server socket) if > they intend to use the module. So I added a module lifecycle, and hacked in > the netty websocket example enough that it starts and stops gracefully and > answers every request with either "parse error" or "not yet implemented" > etc... > > Not sure how much or how often I'll get to fiddle with this, but if it > sounds interesting to, you can read it and comment on it here: > > https://github.com/apache/solr/pull/2759 > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
Re: [JENKINS] Solr » Solr-Check-9.x - Build # 6198 - Still Failing!
Recently, a common exception (org.apache.lucene.store.AlreadyClosedException: this Directory is closed) seen in multiple failed test cases. FAILED: org.apache.solr.cloud.TestPullReplica.testKillPullReplica FAILED: org.apache.solr.cloud.SplitShardWithNodeRoleTest.testSolrClusterWithNodeRoleWithPull FAILED: org.apache.solr.cloud.TestPullReplica.testAddDocs I opened a JIRA and shared findings there. https://issues.apache.org/jira/browse/SOLR-17497
