Please file a JIRA issue so that we can address this.
- Mark
On Jul 2, 2013, at 6:20 AM, Daniel Collins wrote:
> On looking at the code in SolrDispatchFilter, is this intentional or not?
> I think I remember Mark Miller mentioning that in an OOM case, the best
> course of action is basically to
On looking at the code in SolrDispatchFilter, is this intentional or not?
I think I remember Mark Miller mentioning that in an OOM case, the best
course of action is basically to kill the process, there is very little
Solr can do once it has run out of memory. Yet it seems that Solr catches
the O
Thanks for the feedback Daniel ... For now, I've opted to just kill
the JVM with System.exit(1) in the SolrDispatchFilter code and will
restart it with a Linux supervisor. Not elegant but the alternative of
having a zombie Solr instance walking around my cluster is much worse
;-) Will try to dig in
Ooh, I guess Jetty is trapping that java.lang.OutOfMemoryError, and
throwing it/packaging it as a java.lang.RuntimeException. The -XX option
assumes that the application doesn't handle the Errors and so they would
reach the JVM and thus invoke the handler.
Since Jetty has an exception handler that
A little more to this ...
Just on chance this was a weird Jetty issue or something, I tried with
the latest 9 and the problem still occurs :-(
This is on Java 7 on debian:
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23
Recently upgraded to 4.3.1 but this problem has persisted for a while now ...
I'm using the following configuration when starting Jetty:
-XX:OnOutOfMemoryError="/home/solr/oom_killer.sh 83 %p"
If an OOM is triggered during Solr web app initialization (such as by
me lowering -Xmx to a value that
