[
https://issues.apache.org/jira/browse/SOLR-15644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419103#comment-17419103
]
Mark Robert Miller commented on SOLR-15644:
-------------------------------------------
One thing I can’t recall well enough that maybe could be addressed in the test
frame, from fuzzy memory, is terminated threads. But again, only seems to
matter when things are much faster. When things are fast, if I remember
correctly, the test framework treats threads in terminated state as a leak. And
they don’t seem to be resolved until garbage collected. When things are stoped
in a tear down method this never seems to be an issue. But when stopped in an
after class, for some reason terminated threads can hang in much longer. I
found things to be much faster if I simply caught those terminated state
threads early and waited them out vs letting them hit the test framework. I
could also often address it by shutting things down in before/after instead of
after class. But again, I’ve never seen anything like it without tests moving
much much faster.
> Add the ability to interrupt and wait for threads for problematic tests.
> ------------------------------------------------------------------------
>
> Key: SOLR-15644
> URL: https://issues.apache.org/jira/browse/SOLR-15644
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
> Reporter: Mark Robert Miller
> Assignee: Mark Robert Miller
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The stuff in the test framework is slow and lacks control. For problematic
> tests, you don't want to linger first and you want fine control around
> interrupting - interrupting with a sledgehammer approach can actually make
> things take longer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
