> Then we should see some OOM somewhere in a stack trace!
We should. I mean should have. I've written a simple test that OOMs
and it does show up:
test:
[mkdir] Created dir: c:\Work\lucene-solr\lucene\build\core\test
[junit4:junit4] <JUnit4> says g'day! Master seed: D82ABE551D56D0E3
[junit4:junit4] Your console's encoding may not display certain
unicode glyphs: windows-1252
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4] Suite: org.apache.lucene.TestOOM
[junit4:junit4] ERROR 0.32s | TestOOM.testOOM
[junit4:junit4] > Throwable #1: java.lang.OutOfMemoryError: Java heap space
[junit4:junit4] > at
__randomizedtesting.SeedInfo.seed([D82ABE551D56D0E3:330E9B19A0F2DFCD]:0)
[junit4:junit4] > at org.apache.lucene.TestOOM.testOOM(TestOOM.java:28)
I can't predict what's going to happen when the memory is nearly
consumed (and kept) from leaked background threads though -- if this
is the case then nothing's short of preallocating static data
structures is going to help...
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
