james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Can JAMES recover spooled mail after a JVM crash?
Date Tue, 24 Apr 2007 19:40:32 GMT
robert burrell donkin ha scritto:
> i'm now running serverside SIEVE filtering using JAMES :-)

So we really should release jSieve ;-)

> 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?

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 

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?

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

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 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.

> AIUI fetchmail should put my mail onto the spool.
> will spooled mail survive a JVM crash?

Usually yes.
James always remove a message from the spool AFTER having written it in 
another spool or sent it.

> will it be automatically processed next time james starts?
> - robert

Maybe. It depends on the crashing condition. Often Out of memories will 
result in random errors around and maybe some message being processed is 
simply saved into the error repository. In this last case you will have 
to take the messages from the error repository and move back to the spool.

IIRC in JAMES Server trunk there are remote admininistration commands to 
move mails between spool repositories.


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

View raw message