On Fri, Jan 27, 2012 at 10:46 AM, Robert Muir <[email protected]> wrote: > On Fri, Jan 27, 2012 at 10:22 AM, Yonik Seeley > <[email protected]> wrote: >> >> FWIW, these aren't real failures of these particular tests, but >> another test bleeding over into these >> caused by a still-running thread later closing a searcher (and it >> get's counted during whatever test is running at the time). >> > > Hmm, we had this confusion before and thats why we track resource > leaks from tests that still leave threads running > after all afterClass() methods have finished. In lucene we actually > check this on a per-method basis (after tearDown): > because its annoying for a thread to confusingly cause a different > method even in the same test class to fail. > > That's why its important for tests to not leave a lot of threads > running (there are a lot of warnings in solr tests about this):
Yep, I've been planning on moving the facet executor to the Core or CoreContainer so it can be shut down. We'll still have some that aren't in our control though - I've started shutting down the hhtp connection manager used to talk to other solr instances in distrib, but now what I see is "MultiThreadedHttpConnectionManager cleanup". Just like Solr ignores some expected exceptions, we may want a way to downgrade the severity of certain expexted threads still running at the end of tests. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
