I do not know the nature of the email you sent but im many case, it is useful to have some trace of the fact an email was sent with some indication of the content.
The goal is not to replace the mail server queue, the mail server has many other responsibilities, it is to manage the app message exchange. Usually, I prefer to create some sort of persistent queue that contains only meta data about the email to send. The application code fill the queue to create message to send. This queue can manage the SMTP failure and also the flow. Sending 1000s of email in a batch process can trigger many load problems and some system may impose some rate limit. The meta data should contains only the information required to send the message, for example, the "to" email address, a class name or any other name that point to the template or code that will build the message and any parameters required by the template/code. For example, an account statement will require an account number or customer id. The main downside is the message generation need to be completely separated from the user interface and logic code. It may use the logic code but not the UI code. You may add a priority level to separate batch messages from more immediate message like an account reset. A specialized thread send the message and mark them sent with a timestamp. This thread can implements some logic like sending batch only at night, limit the rate to 10 emails/min, etc. This sort of queue allows bounce management, by adding some unique identifier in header and creating a special account that forward the emails sent to sender the app can process the errors, mark the queue entry and trigger some other process. Samuel Le 2014-01-29 à 10:15, Musall Maik <[email protected]> a écrit : > > Am 29.01.2014 um 16:08 schrieb Þór Sigurðsson <[email protected]>: > >> Don't queue the email - that's something the mail server itself is >> proficient at, not the WO framework (or any framework on top of that). > > I’m not talking about re-inventing SMTP servers. But we had a case where the > spooling filesystem of the SMTP server ran full, so it failed to accept any > new email, and data got lost. I only want to ensure that nothing is silently > lost while the app thinks the mail is safely on it’s way out. > >> Instead, log the request - an email was requested. Send the email, and once >> the email has been sent, mark the request as handled. >> That way, if your Wapp happens to turn its toes towards the sky, it still >> has the current state at restart. >> And keep the log small. Very small. It should be fast end efficient (e.g. >> USERID:REQUEST_TYPE:DATE:(BOOL)HANDLED ) > > Where would the restarting app get the lost email content and metadata from? > > Maik > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
