james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Webb" ...@inovem.com>
Subject RE: An interesting note about memory leaks (was Memory leaks in RemoteDelivery mailet?)
Date Thu, 06 Feb 2003 14:00:12 GMT
Taken from the JavaMail 1.3 docs
http://java.sun.com/products/javamail/1.3/docs/javadocs/com/sun/mail/smt
p/package-summary.html


"mail.smtp.from (String) Email address to use for SMTP MAIL command.
This sets the envelope return address. Defaults to msg.getFrom() or
InternetAddress.getLocalAddress(). NOTE: mail.smtp.user was previously
used for this."

"Note that the mail.smtp.user property can be set to provide a default
username for the callback, but the password will still need to be
supplied explicitly. "

This appears to indicate that "mail.smtp.user" property is ONLY required
for SMTP AUTH and not for general use and therefore is NOT required for
James. I've tested this and the headers etc seem to be well-formed and
correct.

The good news is that I can still set "mail.smtp.from" and have no
memory leaks.
Therefore I'd move that the setting of "mail.smtp.user" be dropped as a)
it causes problems and b) it's irrelevant.

I assume that "mail.smtp.user" is possbily causing the SMTP transport to
start up (or think it has to) a SMTP AUTH session. As our usage of this
field is incorrect it may be causing problems as the session over. (This
is a guess)

-- Jason



> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 06 February 2003 09:44
> To: James Developers List
> Subject: RE: An interesting note about memory leaks (was 
> Memory leaks in RemoteDelivery mailet?)
> 
> 
> 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
> > 
> 


---------------------------------------------------------------------
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