DIdn’t mean to imply that the test _should_ be serialized, rather that I’ve
inadvertently done so when something shouldn’t be…
Have fun!
> On May 30, 2020, at 6:23 PM, Ilan Ginzburg wrote:
>
> Erick,
>
> Serializing isn't really an option here, we want to test that execution order
> is not
Erick,
Serializing isn't really an option here, we want to test that execution
order is *not* submission order...
I believe if we wanted to verify the property that this test seems to
assert: "when there are more tasks than the number of executor threads and
all are blocked on a single lock,
Ilan:
Please raise a new JIRA and attach any fixes there, a Git PR or patch whichever
you prefer. Your analysis will get lost in the noise for SOLR-12801. And thanks
for digging! We usually title them something like “harden MultiThreadedOCPTest”
or “fix failing MultiThreadedOCPTest” or
Following Erick’s Bad report, I looked at MultiThreadedOCPTest.test().
I've found a failure in testFillWorkQueue() in Jenkins logs (not able to
reproduce locally).
This test enqueues a large number of tasks (115, more than the 100
Collection API parallel executors) to the Collection API queue
