[
https://issues.apache.org/jira/browse/SOLR-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892277#comment-16892277
]
Hoss Man commented on SOLR-13637:
---------------------------------
git bisect has identified 631edee1cba00d7fa41ac6e8c597a467db56346d as the cause
of a recent spike in reproducible BasicAuthIntegrationTest jenkins failures on
master. (Similar failures have been observed on branch_8x as well but i have
not bisected those)
FWIW: Mikhail did some initial investigation into these failures in SOLR-13545
due to initial speculation that that issue caused the failures, and noted that
they seemed to corrispond to the randomization of using V2 API calls.
nature of failures...
{noformat}
[junit4] 2> 51548 ERROR (qtp206015367-815) [n:127.0.0.1:43556_solr ]
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: No
contentStream
[junit4] 2> at
org.apache.solr.handler.admin.SecurityConfHandler.doEdit(SecurityConfHandler.java:103)
[junit4] 2> at
org.apache.solr.handler.admin.SecurityConfHandler.handleRequestBody(SecurityConfHandler.java:85)
[junit4] 2> at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
[junit4] 2> at
org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:247)
[junit4] 2> at
org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:341)
[junit4] 2> at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)
[junit4] 2> at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)
...
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=BasicAuthIntegrationTest -Dtests.method=testBasicAuth
-Dtests.seed=B292FDDCA6F4D6F2 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=lb-LU -Dtests.timezone=Pacific/Easter -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 5.21s J2 | BasicAuthIntegrationTest.testBasicAuth <<<
[junit4] > Throwable #1: java.lang.AssertionError: expected:<401> but
was:<400>
[junit4] > at
__randomizedtesting.SeedInfo.seed([B292FDDCA6F4D6F2:EFC8BCE02A75588]:0)
[junit4] > at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:151)
{noformat}
...note the seed mentioned in the reproduce line. that's an example of a seed
that fails 100% reliably (on my machine) on master as of both HEAD and
631edee1cba00d7fa41ac6e8c597a467db56346d, but does not fail on the previous
commit ( 7d716f11075f0868535c108b21256a3b91b4a154 ) There are other dozens of
seeds from recent jenkins failures that reliably reproduce in the same way
(NOTE: i did not bisect test them all, but i did manually test a few of them
against 631edee1cba00d7fa41ac6e8c597a467db56346d and
7d716f11075f0868535c108b21256a3b91b4a154)
----
Considering how many "addressing test failures" commits you've had to make as
part of this issue just to address the TestContainerReqHandler failures it
introduced, not to mention these BasicAuthIntegrationTest we've now identified,
I would strongly urge you to please:
# *COMPLETLEY* revert all commits made as part of this issue to date
# refrain from re-committing any related changes until you have a chance to
beast all tests with multiple seeds, since this clear impacts the entire code
base in ways you evidently didn't anticipate
# once you have a unified set of changes w/working tests, re-commit only to
master, and give it a few days to ensure no related failures, before
backporting to branch_8x
> Enable loading of plugins from the corecontainer memclassloader
> ---------------------------------------------------------------
>
> Key: SOLR-13637
> URL: https://issues.apache.org/jira/browse/SOLR-13637
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When we update jars or add/modify plugins no core reloading should be
> required .Core reloading is a very expensive operation. Optionally, we can
> just make the plugin depend on the corecontainer level classloader.
> {code:xml}
> <queryParser name="mycustomQParser" class="my.path.to.ClassName"
> runtimeLib="global">
>
> </queryParser>
> {code}
> or alternately using the config API
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-queryparser": {
> "name": "mycustomQParser" ,
> "class" : "my.path.to.ClassName",
> "runtimeLib" : "global"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
> The global classloader is the corecontainer level classloader . So whenever
> this is reloaded The component gets reloaded. The only caveat is, this
> component cannot use core specific jars.
> We will deprecate the {{runtimeLib = true/false}} option and the new options
> are
> * {{runtimeLib=core}} : means this uses the runtimeLib of the collection
> * {{runtimeLib= global}} : means this uses the runtimeLib of the
> corecontainer
> example command to update global jar . This will lead to a reload of all
> components marked as {{runtimeLib=global}}
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "update-runtimelib": {
> "name": "lib-name" ,
> "url" : "http://host:port/url/of/jar";,
> "sha512":"<the-new-sha512>"
> }
> }' http://localhost:8983/api/cluster
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
