> I wouldn't want to see the thread stacks until the test finally timed > out at which point I'd like to see N of them.
I don't think it will be possible since there is no explicit trigger that signals a timeout... although maybe there is -- I think the test framework attempts to send an interrupt signal to all threads within the test group; maybe this could be used as a stimulus for dumping previously saved stack traces. I once had a more "intelligent" periodic stack analyzer -- one that analyzed a series of stack traces and looked for the common root, the diverging stack frame, etc. It could tell you immediately whether a given thread was stalled on something or if it was running in a loop under a given method, etc. It should be in randomized runner's history. > It would spawn a new thread for each test case right? And it'd have > to stop that thread when the test completes (success or failure)... Pretty much. Otherwise you'd run into problems with thread leak detection that's built into the runner. Or you could make this thread run per the entire suite, not for each individual test -- this would be much faster (in particular in the presence of repeats). Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
