You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Daniel Perry <d....@netcase.co.uk> on 2005/05/05 17:15:24 UTC
RE: Serious bandwidth begin consumed by James
Now this problem has hit our server.... And in the last ten days or so
consumed an enormous amount of bandwidth!
An 18mb email was sent to an address that is forwarded elsewhere (via
jdbcvirtualusertable). The server it is forwarded to has a 10mb limit, so
it responded with "552 Message size exceeds maximum permitted".
Now I've looked through the code, and it all looks good - permanent error,
so send bounce, and delete original message. But this wasn't happening.
Now here's the catch - delivering the bounce caused a
java.lang.OutOfMemoryError. So, the bouncing never completed, and this is
not caught by the "catch Exception" block around getMailetContext().bounce,
but is caught in RemoteDelivery.run()!
I changed the code to catch all "Error"s on bouncing, not just "Exception"s.
-----------------------patch
--- C:\RemoteDelivery.java.orig Thu May 05 15:42:37 2005
+++ C:\RemoteDelivery.java.fixed Thu May 05 15:50:30 2005
@@ -740,12 +740,12 @@
log("Sending failure message " + mail.getName());
try {
getMailetContext().bounce(mail, sout.toString());
} catch (MessagingException me) {
log("Encountered unexpected messaging exception while bouncing
message: " + me.getMessage());
- } catch (Exception e) {
- log("Encountered unexpected exception while bouncing message: "
+ e.getMessage());
+ } catch (Error e) {
+ log("Encountered unexpected exception/error while bouncing
message: " + e.getMessage());
}
}
public String getMailetInfo() {
return "RemoteDelivery Mailet";
-----------------------end of patch
However, looking at remotedelivery.run, it seems like it was designed to
handle this kind of problem - but only removes messages that fails with an
exception, not an error or throwable:
} catch (Exception e) {
// Prevent unexpected exceptions from causing looping by removing
// message from outgoing.
outgoing.remove(key);
throw e;
}
} catch (Throwable e) {
if (!destroyed) log("Exception caught in RemoteDelivery.run()", e);
}
Maybe this code should be catch all errors, and try to remove the mail!
Daniel.
> -----Original Message-----
> From: Stefano Bagnara [mailto:io@bago.org]On Behalf Of apache@bago.org
> Sent: 14 April 2005 21:04
> To: 'James Users List'; chris@itsolut.com
> Subject: Re: Serious bandwidth begin consumed by James
>
>
> > I did a little digging in the logs and I was able to find
> > these repeated log entries in the mailet-* logs (I removed
> > the actual email address/dns info to protect the innocent):
>
> It seems the same message that once failed bounces and resend
> again. This is
> really strange.
> RemoteDelivery, after it says "Sending failure...":
>
> log("Sending failure message " + mail.getName());
> try {
> getMailetContext().bounce(mail, sout.toString());
>
> Will call MailetContext.bounce. James.java, bounce():
>
> if (mail.getSender() == null) {
> if (getLogger().isInfoEnabled())
> getLogger().info("Mail to be bounced contains a null (<>)
> reverse path. No bounce will be sent.");
> return;
> } else {
> // Bounce message goes to the reverse path, not to
> the Reply-To
> address
> if (getLogger().isInfoEnabled())
> getLogger().info("Processing a bounce request for
> a message
> with a reverse path of " + mail.getSender().toString());
> reply.setRecipient(MimeMessage.RecipientType.TO,
> mail.getSender().toInternetAddress());
> }
>
> You should find a log containing one of these 2 logs "Mail to be bounce
> contains" or "Processing a bounce request"... Please find that
> log and tell
> us what you find.
>
> But I think I found the problem: the bounce created has the full
> message as
> attachment and so it is bigger than the original. The
> domain.here.com refuse
> big messages as like the graphicsbyheather.com server so the message keeps
> bouncing.
> This is a problem in the current 2.2.0. I rememeber something fixed about
> return-path handling in the current 2_1_fcs branch. You should
> try upgrading
> to "2.2.1dev" (branch 2_1_fcs in current subversion). This should
> be fixed.
>
> Alternatively you probably can fix this by adding a <bounceProcessor> tag
> like described in this JIRA issue:
> http://issues.apache.org/jira/browse/JAMES-357
>
> The bug will be still there but the bounce will be created by DSNBounce
> instead of the MailetContext and I think that DSNBounce will correctly set
> the return-path of the bounce to "<>". You can even configure the
> DSNBounce
> with the option <attachment>none</attachment> so that the bounce will not
> contain the original message!
>
>
> > mailet-2005-04-13-00-01.log:13/04/05 14:10:28 INFO James.Mailet:
> > RemoteDelivery: Attempting delivery of Mail1113353072629-556
> > 45-to-graphicsbyheather.com to host mx.domain.here.com. at
> > 217.160.230.10 to addresses [someuser@domain.here.com]
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:38 INFO James.Mailet:
> > RemoteDelivery: Exception delivering message (Mail1113353072
> > 629-55645-to-domain.here.com) - 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:38 INFO James.Mailet:
> > RemoteDelivery: Permanent exception delivering mail (Mail111
> > 3353072629-55645-to-domain.here.com:
> > javax.mail.MessagingException: 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:44 INFO James.Mailet:
> > RemoteDelivery: Sending failure message Mail1113353072629-55
> > 645-to-domain.here.com
> >
> > mailet-2005-04-13-00-01.log:13/04/05 14:13:45 INFO James.Mailet:
> > RemoteDelivery: Attempting delivery of Mail1113353072629-556
> > 45-to-graphicsbyheather.com to host mx.domain.here.com. at
> > 217.160.230.12 to addresses [someuser@domain.here.com]
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:27 INFO James.Mailet:
> > RemoteDelivery: Exception delivering message (Mail1113353072
> > 629-55645-to-domain.here.com) - 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:27 INFO James.Mailet:
> > RemoteDelivery: Permanent exception delivering mail (Mail111
> > 3353072629-55645-to-domain.here.com:
> > javax.mail.MessagingException: 552 message too large
> > mailet-2005-04-13-00-01.log:13/04/05 14:18:42 INFO James.Mailet:
> > RemoteDelivery: Sending failure message Mail1113353072629-55
> > 645-to-domain.here.com
> >
> > This group of messages repeated from 8pm 4/12 when the
> > message was sent by one of my users until 2:30 4/13 when I
> > killed the server and removed all of the outgoing mail
> > messages. It looks like they repeat in 3 minute increments.
> >
> >
> > Chris....
> >
> >
> > Serge Knystautas wrote:
> >
> > > Chris Hane wrote:
> > >
> > >> What I think is happening though is the other server that james is
> > >> trying to send to is not allowing for such a large message and is
> > >> just terminating the connection.
> > >>
> > >> It appears that james takes the termination as a network error and
> > >> retries immediately (and gets itself into a loop). Has
> > anyone else
> > >> seen this type of issue? Any solutions? I'm even willing to work
> > >> through some of the james code if I could get a pointer or
> > two with
> > >> which classes to start with in my debugging attempts.
> > >
> > >
> > > What version are you running? I can't think of how our
> > error handling
> > > would try to immediately resend without incrementing the attempt
> > > counter. Maybe it's an old version with a bug that's since
> > been fixed.
> > >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.9.7 - Release Date: 4/12/2005
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-user-help@james.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Serious bandwidth begin consumed by James
Posted by Daniel Perry <d....@netcase.co.uk>.
Yup, in our server i decided to just catch Throwables from the bounce
attempt (if a bounce fails, tough!)
Still, it seems a little concerning that the server may get low on memory,
then attempt to deliver a reasonably sized mail (within server limits) and
fail, and consequently keep repeating (and failing to load it).
I cant work out what to do here. I guess the correct behaviour would be to
queue this message (ie treat OutOfMemory as temporary error). In which case
it needs to be cought and dealt with appropriately. I might take a look at
the code again and see if i can figure this out (when i get a free minute!)
Daniel.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 03 June 2005 22:00
> To: James-Dev Mailing List
> Subject: RE: Serious bandwidth begin consumed by James
>
>
> Daniel,
>
> I was going to make a change to the code, at the outer level but actually,
> I've got a concern. If something ELSE in the server led to OutOfMemory
> conditions, we'd start purging the outgoing spool. That would be
> catastrophic.
>
> I'll look at the specific case of the bounce message. I believe that the
> real fix is to NOT bounce the message, but to simply send the
> bounce notice.
> Ideally, that should be a DSN, but Stefano is working on that code.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Serious bandwidth begin consumed by James
Posted by "Noel J. Bergman" <no...@devtech.com>.
Daniel,
I was going to make a change to the code, at the outer level but actually,
I've got a concern. If something ELSE in the server led to OutOfMemory
conditions, we'd start purging the outgoing spool. That would be
catastrophic.
I'll look at the specific case of the bounce message. I believe that the
real fix is to NOT bounce the message, but to simply send the bounce notice.
Ideally, that should be a DSN, but Stefano is working on that code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org