> Norman,
>
>> > I'm back to running a test. Started JAMES
>> > with -server -Xms128M -Xmx256M -Xrunhprof heap=sites,depth=12
>
>> > If this will just run for 48-72 hours, hopefully I can gather
>> > some useful data.
>
>> let us see what the new debugging show us ;-)
>
>
> So far, I have a working hypothesis, but will continue to monitor the
> heap.
>
> We may be getting hit by the known-to-be-bad cache inside of InetAddress.
> After 12 hours or so, InetAddress cache related objects appear to be in
> excess of 20% of heap usage, and increasing. From where? It appears to
> be
> a single line in the SMTP handler that was changed in trunk, but not
> backported.
>
> 2.3.0:
> remoteHost = socket.getInetAddress().getHostName();
>
> trunk:
> remoteHost = dnsServer.getHostName(socket.getInetAddress());
>
> The dnsServer call does:
>
> public String getHostName(InetAddress addr){
> try {
> return org.xbill.DNS.Address.getHostName(addr);
> } catch (UnknownHostException e) {
> return addr.getHostAddress();
> }
> }
>
> which does not use the InetAddress cache.
>
> By the way, a bit of observation regarding garbage collection. Because of
> the memstat instrumentation in RemoteManager, I can make sure to take heap
> dumps only and immediately after the JVM does a full GC. And I can see
> that with 1.4.2_09 under load and with heap dumping on, it doesn't appear
> to
> GC at all until it must. Asking for a GC under load doesn't often provide
> one, so it is good to know when one *does* happen. When I want to dump
> the
> heap, I just keep watching for the full GC, and then I request the dump.
>
> --- Noel
>
>
>
The Problem is that we need "many" changes to backport this.. And we
agreed that we ony want to backport "critical" stuff..
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
