I've found the problem, and its not any of our code ;) I blame JavaMail
In org.apache.james.transport.RemoteDelivery.java
                        //This was an older version of JavaMail
                       if (mail.getSender() == null) {
                            props.put("mail.smtp.user", "<>");
                            props.put("mail.smtp.from", "<>");
                        } else {
                            String sender = mail.getSender().toString();
                            props.put("mail.smtp.user", sender);
                            props.put("mail.smtp.from", sender);
                        }        
This code causes the leak. I've tested this by sending 400000 messages
through James as a relay. If this code is in then the heap size grows to
the maximum allowed and then halts further mail processing. If the code
block is comment out/removed then the VM grows no bigger than the
minimum, mail delivery is still fine after 24 hours and a full GC puts
the memory down to about 3Mb used. Very happy
If I take it out there seem to be no ill effects on mail delivery, so
I'm curious to know why the props.put() is there. 

Thanks for your help all, particularly Noel. After using OptimizeIt,
Numega DevParter, -xrunhprof and the gc log I hope I've nailed it

The reason I haven't posted a patch is that I'd like an answer to why
the puts are done. If no one knows then I'll post a patch removing the
above code block.

-- Jason

> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: 05 February 2003 17:49
> To: James Developers List
> Subject: RE: An interesting note about memory leaks (was 
> Memory leaks in RemoteDelivery mailet?)
> 
> 
> > However, I still get a leak over time.
> 
> Please use the heap profiler, and let us know what you find.  :-)
> 
> > I think the problem is in the deliver() in RemoteDelivery(). I WILL 
> > find it :)
> 
> <<grin>>  Been there, done that.  I spent long hours finding 
> them earlier in the pipeline.  I'm looking forward to your findings.
> 
> My suggestion to you is that delete everything from the 
> pipeline, and put RemoteDelivery directly at the top of the 
> root processor to isolate it.
> 
>       --- Noel
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to