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:[EMAIL PROTECTED]]
> 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:[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]
>
