james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject Re: [bump]RE: Serious bandwidth begin consumed by James
Date Fri, 03 Jun 2005 11:37:45 GMT
looks sensible to me Dan. Go for it.

d.



|---------+---------------------------->
|         |           "Daniel Perry"   |
|         |           <d.perry@netcase.|
|         |           co.uk>           |
|         |                            |
|         |           03/06/2005 11:07 |
|         |           Please respond to|
|         |           "James Developers|
|         |           List"            |
|         |                            |
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                      
                                        |
  |       To:       "James Developers List" <server-dev@james.apache.org>          
                                              |
  |       cc:                                                                            
                                        |
  |       Subject:  [bump]RE: Serious bandwidth begin consumed by James                  
                                        |
  >-------------------------------------------------------------------------------------------------------------------------------|




Did anyone else ever look into the (serious) issues i highlighted with the
SMTP protocol handler and remote delivery mailet?

1. endless remote delivery retries on an exception when remote delivery
bounces a message (initial problem) - can be delt with using the patch i
supplied, to catch the error, and treat it in same way as exceptions.
2. Error (eg. OutOfMemoryError) at any point in remote delivery causes
endless retries, as only exceptions cause dropping of message, not errors.
3. Non RFC compliant rejection of messages over size limit, and this also
screws up the remainder of the SMTP session.

See the two blocks below of my origional message for code/comment on
solutions.

Are my solutions ok? (before i go away and code).  If i produce patches
against head and submit it to JIRA, is anyone interested?

Daniel.



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





> Assuming my understanding of the code and rfcs is correct, it means that
> james enters a blackhole phase, where james basically does
> nothing until it
> receives a proper smtp command, and then it doesnt get it's state reset,
> which all seems wrong in light of the rfcs.
>
> If i am right, it should:
> Notice to size limit has been reached, and stop buffering the message.
> Continue reading the message until <crlf>.<crlf> is reached
> Send 552 error!
> Reset state, and continue to accept other messages.
>
> I think it should do this by:
> Upon catching the size exception,
> gobble away at the CharTerminatedInputStream (need to keep a reference to
> this) until eof.
> then continue as before, but:
> Also, Get rid of MESG_FAILED state, and call resetState so we can
> allow the
> parsing/logging/responses-to further commands/messages to work properly!
>
> Does this make sense?
>
> Daniel.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org





***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer
viruses.

**************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message