james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: Can JAMES recover spooled mail after a JVM crash?
Date Tue, 24 Apr 2007 22:03:39 GMT
On 4/24/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:
> > i'm now running serverside SIEVE filtering using JAMES :-)
>
> So we really should release jSieve ;-)

it's running but there are issues that i need time to track down
properly. i'm pretty sure that they are IMAP related but i need to be
sure.

> > unfortunately, my email box died :-(
> > i'm now running JAMES on my main development machine. JAMES now seems
> > to crash with an out of memory exception in a thread named
> > 'CompilerThread1' when i download my mail.
>
> Well, we saw this report from many users lately. The "weird" think is
> that it always happen in a CompilerThread1 like this one:
> ---
> Exception in thread "CompilerThread0" java.lang.OutOfMemoryError:
> requested 134217736 bytes for Chunk::new. Out of swap space?
> ----
>
> What James version are you using?

my personal fork based on older trunk plus my IMAP

maybe i need to push the modularisation forward so that i can use HEAD
+ personal module

> I never had/seen this error, but at least 2-3 users reported it.
>
> Here is my last reply to such a report:
> --
> Another user, SeaGizmo, reported the same identical error 1 month ago
> (23/03/2007).
>
> He was using jdk1.5.0_10 on linux.
>
> The first suggestion was to upgrade to 1.5.0_11 or to downgrade to
> 1.4.2_13. Can you try?

not easy to downgrade: i'm 1.5.0_11 on 64bit linux

not sure that i could easily upgrade either

> Then Salvatore Orlando suggested this to proceed with analysis:
> ------------------
> This crash seems to be related to a JVM bug. It sounds quite strange that a
> method requires more than 100MB heap for Jit Compilation. You can find
> several similar failure reports in the hotspot bug database.
>
> In this case it could be useful to monitor the following parameters through
> jvmstat:
>
> 1) sun.ci.lastFailedMethod
> You should be able to identify which JIT compilation event leads to the
> failure of the JVM. (You can also write a little JVMTI agent implementing
> the compiledMethodLoad callback function).
> 2) sun.ci.lastFailedType
>
> Once the faulty method has been identified it can be excluded from jit
> compilation creating a .hotspot_compiler file (including the name of the
> methods to exclude preceeded by the 'exclude' keyword) and passing this file
> to the JVM through the -XX:CompileCommandFile option.
>
> 3) sun.ci.nmethodSize
> If several failures are observed, and they occur upon JIT-compilation of
> different methods there may exist a problem with the native code cache. This
> parameter allows you to monitor the usage of this area (by default on
> LinuxX86 the JVM reserves 48M to this aim)
> --------------------------

i'll set this up tomorrow

> I think they solved simply by increasing the Xmx parameter, but this
> doesn't convince me too much as the error always happen on the
> CompilerThread and that thread should not be doing "almost" anything
> after James is running for a while.

what does it do?

my failure only happens with load not under standard operation. JAMES
totally maxes out my box during processing the mail then fails towards
the end of the process.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message