[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837695#comment-16837695
]
Hoss Man commented on SOLR-13464:
---------------------------------
Some examples of the types of failures i've been investigating...
(NOTE: we've seen multiples of each of these on various branches/jvms/hardware)
http://fucit.org/solr-jenkins-reports/job-data/thetaphi/Lucene-Solr-8.x-Windows/246
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=BasicAuthIntegrationTest -Dtests.method=testBasicAuth
-Dtests.seed=117DFCDACC8975B4 -Dtests.slow=true -Dtests.locale=en-MS
-Dtests.timezone=AST -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] ERROR 8.62s J0 | BasicAuthIntegrationTest.testBasicAuth <<<
[junit4] > Throwable #1:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:58528/solr/authCollection: Error from server at
null: Expected mime type application/octet-stream but got text/html. <html>
[junit4] > <head>
[junit4] > <meta http-equiv="Content-Type"
content="text/html;charset=utf-8"/>
[junit4] > <title>Error 401 require authentication</title>
[junit4] > </head>
[junit4] > <body><h2>HTTP ERROR 401</h2>
[junit4] > <p>Problem accessing
/solr/authCollection_shard2_replica_n2/select. Reason:
[junit4] > <pre> require authentication</pre></p><hr><a
href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.14.v20181114</a><hr/>
[junit4] > </body>
[junit4] > </html>
[junit4] > at
__randomizedtesting.SeedInfo.seed([117DFCDACC8975B4:AD138AC868DAF6CE]:0)
[junit4] > at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
[junit4] > at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
[junit4] > at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
[junit4] > at
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
[junit4] > at
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
[junit4] > at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068)
[junit4] > at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837)
[junit4] > at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
[junit4] > at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:290)
...
{noformat}
http://fucit.org/solr-jenkins-reports/job-data/thetaphi/Lucene-Solr-master-Linux/24054
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=BasicAuthIntegrationTest -Dtests.method=testBasicAuth
-Dtests.seed=C9DDA6254F404BB5 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=nn-NO -Dtests.timezone=CNT -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 8.80s J1 | BasicAuthIntegrationTest.testBasicAuth <<<
[junit4] > Throwable #1: java.lang.AssertionError: must have failed
[junit4] > at
__randomizedtesting.SeedInfo.seed([C9DDA6254F404BB5:75B3D037EB13C8CF]:0)
[junit4] > at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:204)
...
{noformat}
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]