I think that Pete means that if your local mail server is down, you cannot send anything.
I've solved this myself by using a ScheduledExecutorService. I put each email in this, and cancel when the sending was successful. Here's the code:
In short, I schedule the message to be sent immediately, and every minute after that. If the sending is successful I cancel the task again so it will be taken out of the scheduler. If not, may next minute.
If you have a multi-threaded service you can make the run method wait until the future is set; that way the task won't get triggered a second time where all it will do is cancel itself.
Another possible solution which comes to mind could be to integrate a readily available mail server into your app. Then you would have the advantage that the mail server already knows how to handle mail failures and retry to send mails for some time, as Ulf pointed out. And you wouldn't have to take care if a peer mail server is down because the integrated mail server already would handle this scenario. Of course that would require that your application is running all the time. Or maybe the mail server itself would provide any persistent storage for mails.
I don't know for sure, but maybe James or parts of it can be used from inside an application without running it as a standalone application?!?
Joined: Feb 18, 2005
I would like to keep the application as simple as possible. It's purpose is mainly to send out notifications with attachments. It's important that the emails are acknowledged and if not stored for some time.
When I talk about the downtime of the server I mean the peer server which receives the messages.
So is it a better idea to use a real java mail server option like James (or something similar) or rely on storing messages in a message queue?
I might need features like statistics about send messages & failures in the future.
I think both options would be OK. What I wanted to point out with my last post is that a mail server (which allows integration into your application) MAYBE requires less work because it would already take care for re-sending mails properly in case of failures and I can imagine that a mailing solution like this already has something like a persistent queue mechanism built-in, so you don't have to do this work yourself either.
Unfortunately, as I wrote, I don't know if James is a possible solution. I don't know if it's embeddable into another Java application and I don't know if it offers some kind of permanent mail store (=queue). But I'm sure the documentation will tell you about it
Regarding your requirement to provide statistics: I think there would be many solutions ranging from writing the necessary data by hand and create the output you want to using available tools to parse an existing mail server log. It depends...