I'm refactoring LuceneTestCase trying to get rid of certain ugliness
(well, very subjective). A lot of problems are caused by static
methods
because we don't know when values returned from them should be
disposed of/ cleaned up. If this were known, we could pinpoint
leakages more accurately. For example Directories should be closed and
this is currently verified at suite scope but there's nothing wrong
with declaring that they should be closed after a given test case. I
added two facade methods to LuceneTestCase that do close resources at
the end of respective scope:
/**
* Registers a {@link Closeable} resource that should be closed
after the test completes.
*/
public <T extends Closeable> T closeAfterTest(T resource) {
return RandomizedContext.current().closeAtEnd(resource,
LifecycleScope.TEST);
}
/**
* Registers a {@link Closeable} resource that should be closed
after the suite completes.
*/
public static <T extends Closeable> T closeAfterSuite(T resource) {
return RandomizedContext.current().closeAtEnd(resource,
LifecycleScope.SUITE);
}
I then successfully replaced the existing code returning Directory
instances (which used a Map of resources to allocation stack trace)
and it works pretty much identically.
Anyway, I have a question concerning newSearcher. It currently
allocates a IndexSearcher with a ThreadPoolExecutor but fails to close
it properly. The scenario for failure (one, possibly others exist) is
that IndexReader is allocated per suite scope but IndexSearcher is
allocated per-test. This causes IndexReader to be open across multiple
tests and the threadpool is not closed until the IndexReader is closed
(which causes thread leaks).
I can make this call context-sensitive and close the threadpool to
shutdown after the current context is disposed of (so, if newSearcher
is called from a @BeforeClass then the threadpool would be valid until
the end of the suite; if it's called from a test, it'd be closed after
the test). An alternative (which also works) is to allow thread leaks
to propagate to the suite scope (which is fine, but not as elegant).
Any thoughts?
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
