james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: An interesting note about memory leaks (was Memory leaks in RemoteDelivery mailet?)
Date Thu, 06 Feb 2003 09:44:21 GMT
JavaMail spec defines certain default properties which must be supplied.
But because JavaMail is a mail client API it assumes that these values will be constant, in
our case this is patently not so.
JavaMail uses the message recipents and sender, but this may not be the correct smtp MAIL
FROM and RCPT TO values, and the other send methods  only allow you to specify recipients,
not a sender other than the From: header.

I suggest that you ought to carry out some qualitative, in the light of this, tests on mail
sent without this code, and let us know your findings.
I'd be particularly interested in seeing what happens to aliased mail where the recipients
are not in the message header (eg listserve), and messages with a missing From: header.

d.


> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 06 February 2003 09:12
> To: 'James Developers List'
> Subject: RE: An interesting note about memory leaks (was Memory leaks in
> RemoteDelivery mailet?)
> 
> 
> 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:noel@devtech.com] 
> > 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: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
> 
Mime
View raw message