james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-592) James leaks memory slowly
Date Fri, 03 Nov 2006 14:57:18 GMT
    [ http://issues.apache.org/jira/browse/JAMES-592?page=comments#action_12446977 ] 
Noel J. Bergman commented on JAMES-592:

Yes.  We discussed Serge's e-mail at the time (the InetAddres part was old news, even then),
have aleady made changes related to the dnsjava cache, and were supposed to have eliminated
all uses of InetAddress for resolution.  It just seems that in v2.3.0, we missed a few places
that still populated the InetAddress cache instead of calling dnsjava.

We have known about this problem for years, which is why we had previously set about removing
all uses of InetAddress for resolution from the code.  We just missed some.  See also http://www.rgagnon.com/javadetails/java-0445.html,
which explains the problem you had (as also noted by http://java.sun.com/j2se/1.4.2/docs/api/java/net/InetAddress.html
for JDK 1.4 and http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html for JDK 5, the
non-Sun properties are security policy properties).

The proper solution is to use dnsjava for everything, and avoid anything that impacts the
InetAddress cache.

> James leaks memory slowly
> -------------------------
>                 Key: JAMES-592
>                 URL: http://issues.apache.org/jira/browse/JAMES-592
>             Project: James
>          Issue Type: Bug
>    Affects Versions: 2.3.0
>            Reporter: Norman Maurer
>         Assigned To: Noel J. Bergman
>            Priority: Critical
> Noel wrote on list:
> I do not know where in the application it is happening, but after running
> JAMES non-stop since Fri Aug 11 03:29:57 EDT 2006, this morning the JVM
> started to throw OutOfMemoryError exceptions, such as:
> 21/08/06 08:39:47 WARN  mailstore: Exception retrieving mail:
> java.lang.RuntimeException: Exception caught while retrieving an object,
> cause: java.lang.OutOfMemoryError, so we're deleting it.
> That did not recover, so it wasn't just due to a transient large allocation
> (which I limit, anyway), so there is definitely something leaking, albeit
> slowly.  Keep in mind that the store was one of the victims, but not
> necessarily the cause.
> The JVM process size had steadily grown from a somewhat stable 114MB to
> 130MB last night.  I did not look at it this morning before restarting the
> server.
>         --- Noel

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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

View raw message