[
https://issues.apache.org/jira/browse/SOLR-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178556#comment-17178556
]
Erick Erickson commented on SOLR-14750:
---------------------------------------
[~dsmiley] Thanks, that gives me some idea where to look. The problem is the
coreId check is bogus. CoreContainer.reload(name, coreId) is never called
except from CoreContainer.reload(name), and it's _always_ null. In essence,
that return is never hit with this test in place. Which explains why taking it
out made TestBulkSchemaConcurrent pass, but not what it _should_ be doing. If
it's there to keep from unnecessary reloads, it's not doing it.
[~noble] do you have any insights here? SOLR-14151 has no changes that call
CoreContainer(name, coreId) directly that I could see on a quick scan, they all
call CoreContainer.reload(name).
> Harden TestBulkSchemaConcurrent
> -------------------------------
>
> Key: SOLR-14750
> URL: https://issues.apache.org/jira/browse/SOLR-14750
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Attachments: SOLR-14750.patch
>
>
> This test has been failing quite often lately. I poked around a bit and see
> what I _think_ is evidence of a race condition in CoreContainer.reload where
> a reload on the same core is happening from two places in close succession.
> I'll attach a preliminary patch soon.
> Without this patch I had 25 failures out of 1,000 runs, with it 0.
> I consider this patch a WIP, putting up for comment. Well, it has nocommits
> so... But In particular, I have to review some changes I made about which
> name we're using for PendingCoreOps. I also want to back out my changes and
> beast it again with some more logging to see if I can nail down that multiple
> reloads are happening before declaring victory.
> What this does is put the name of the core we're reloading in pendingCoreOps
> earlier in the reload process. Then the second call to reload will wait until
> the first is completed. I also restructured it a bit because I don't like if
> clauses that go on forever and a small else clause way down the code. I
> inverted the test and bailed out of the method rather than fall off the end
> after the else clause.
> One thing I don't like about this is two reloads in such rapid succession
> seems wasteful. Even so, I can imagine that one reload gets through far
> enough to load the schema, then a schema update changes the schema _then_
> calls reload. So I don't think just returning if there's a reload happening
> on that core already is valid.
> More to come.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
