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
