When the Connection Fails

[vdennis]

Hey All!
We use SMTPmail for batch processing of emails, and it has worked really well. We have a split system in that the back end is UNIX, and that is where most the email are generated from. The front side is GUI, windows base.

About 1 month ago our exchange server when down for a long time and as a result about 1000 automatically generated emails got 'lost' because there was nothing to connect to. My question is has anyone else had this issue and if so how did you correct it?

My original thought was to store the parameters, and more the attachment if there was one into a progress table and wait for the service to become available again. But can anyone think of a better way.

Thanks,
-Dennis-

 

[GregTomkins]

You need some kind of a message store in between your app and Exchange. It could be based on a Progress table, or something external like a message queue. Heck, you could use flat files if you wanted.

The concept is the same, the appropriate choice depends on your exact situation. In general, the Progress table way is probably simpler but less extensible, but both of those points are debatable.

 

[MaximMonin]

smtpmail returns false if there is any error while sending e-mail.

We use tasks for most background processes. Every task has it's status, which determine what step to do next.
In this paradigm it is easy to repeat failed steps.
+ it gives admin chance to see what tasks still running and make some job manually, or fix problem and push task to next step

 

[vdennis]

We have a generic table I am planning on using. I was just wondering if anyone else ran into this and had a better solution. The day that brought this to my attention, we have over 1,000 failed emails generated over a period of about 48 hours. My plan is to store all the var's being passed to smtpmail, rename any attachment to a unique name and move the attachmentt file to a safe location. Once the problem has corrected run a program to read the table, get the attachment, and send the email. Another use would be for emails with bad data being passed, so the contents would not be lost. All this is missing in the current process but easy to correct. Our problem is that in putting this into place will require a complete re-compile, and smtpmail runs in GUI, CHAR as well AppServer. That takes about an hour making it somewhat hard in testing. Thanks for the response. -Dennis-

 

[tamhas]

The simplest solution might be to make the db a regular part. I.e., instead of each program sending mail directly, have all the sending programs build a db table entry, put attachments in a standard place, etc. Then, have a daemon process which reads this table, sends the mail, and then deletes the entry. If the mail is down, it just piles up in the table until it comes back up again and all of the processes continue with no idea there is a problem. This also gives you a single point to monitor for failure and you can keep track of the contents of the table to see how backed up you are.