Add retry capability to Mailet

[Scott Mitchell <sm...@silverpop.com>]

Hello, we are attempting to use James as an SMTP front end to our
application. I've started work on the Mailet and things are generally
proceeding smoothly. I'm now at the point of adding logic to handle the
situation when our backend system is down. The desired behavior is to
requeue the email (or never take the email out of the spool to begin
with) and retry delivery again after some reasonable amount of time. 

 

I have tried several different combinations so far, none of which were
very satisfactory, so I thought I'd throw it out to the group to see if
there are any best practices in this area. Here's what I've tried so
far:

 

* If the backend system is down my Mailet sets the MailConfig state to a
processor called "retry". This processor simply moves the mail message
back to my primary processor to try again. This worked except that it
retried constantly, without pause, and I think it would just keep
spinning like mad until the backend came back up. Here's the retry
processor definition just in case that's of interest:

 

      <processor name="retry">

         <mailet match="All" class="ToProcessor">

            <processor> xt </processor>

         </mailet>

      </processor>

 

* I've also tried changing the matcher on my custom Mailet to something
that never matches to see what happens to mail that never gets matched.
I was thinking that if this happened to leave the mail in the spool then
I would just create a custom Matcher that checked our backend system
status and only match messages when the system was up. Unfortunately the
result there was that the messages wound up in the "error" spool.

 

* I have looked at the RemoteDelivery Mailet since it has retries and
delayTimes build into it, but that doesn't quite seem to fit either. 

 

* Finally, I tried tweaking my "retry" processor to just stick the mail
back in the spool so that it can be tried again, but that seemed to just
error out on me. Here's an example of that:

      <processor name="retry">

         <mailet match="All" class="ToRepository">

            <destinationURL>file://var/mail/spool/</destinationURL>

         </mailet>

      </processor>

 

So, anyone have any good suggestions? One other requirement I should
mention is that I am not allowed to lose ANY MESSAGES EVER (yep, they
said it like that). So I obviously can't have these things only living
in memory in case James gets restarted while the backend system is down.
I really need them persisted on disk.

 

Thanks,

Scott

Re: Add retry capability to Mailet

[Mark Derricutt <ma...@talios.com>]

Hey there,

This is how I've setup our application using james to handle retries...

In my config.xml I have to processors setup:

        <processor name="resend">
            <mailet match="All" class="ToProcessor">
                <processor>resender</processor>
            </mailet>
        </processor>

        <processor name="resender">
            <mailet match="All" class="MMHandlerMailet">
                <log4j.configuration>log4j.properties</log4j.configuration>
            </mailet>
        </processor>

My mailet does a try/catch around its processing (sending messages over RMI
to the actual server) and if any exceptions occur then I tell it to set the
state as resend:

  mail.setState(RESEND);

I'm not sure off hand why I chain resend to resender, I vaguely remember
having to do this for some reason ( I think I wanted/needed to differentiate
between being a message being told to resend, and being resent), the
resender processor is identical to my main processor but uses the different
name so I can handle pausing a resend in the mailet:

  if ("resender".equalsIgnoreCase(mail.getState())) {
    ...
    Thread.sleep(30000);
  }


Hope this helps..


On 3/16/07, Scott Mitchell <sm...@silverpop.com> wrote:
>
> Hello, we are attempting to use James as an SMTP front end to our
> application. I've started work on the Mailet and things are generally
> proceeding smoothly. I'm now at the point of adding logic to handle the
>