: If you don't like the limit for your specific test: use
: @SuppressFileSystems annotation to suppress it.
:
: But it is really insane for a unit test to use so many index files,
: and it is important to reproduce such bugs when they do happen.
i'm not disagreeing with the value of HandleLimitFS.
I'm saying that in tests like TestIndexSorting.testRandom3 -- where the
point is to create 2 distinct indexes and compare some things about them
-- having a single limit for the entire JVM isn't as useful as if there
was an easy way to just limit the number of open files per index (or for
the test to declare "treat these indexes as if they were on distinct
filesystems").
a knob/hook like this would also be useful in distributed Solr tests, to
say "we want this simulated solr nodeA to act as if it has it's own
filesystem independent from nodeB's filesystem" -- that way we can still
have the benefit of sanity checks that code isn't using too many files
(per *NODE*) and we wouldn't need to use a sledghammer of completely
supressing HandleLimitFS in tests.
Perhaps, in an ideal world, when tests call
LuceneTestCase.createTempDir(...) they could (optionally) pass in some
identifier for what (conceptual/virtual) filesystem they want to use -- so
they default is to assume all temp dirs created in a test come from the
same (mock) filesystem using HandleLimitFS with a (shared) max ... but
tests like TestIndexSorting.testRandom3 could request that the 2 distinct
indexes live ontheir own filesystems; and things like Solr's cloud test
scaffolding could request that each node get their own "virtual"
filesystems (with their own limits)
?
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
