I really appreciate all the time you've spent explaining/assisting me in this.
What is happening in my scenario is that it the maillist gets part way into sending emails to the list members, then the failure occurs and it aborts. But it immediately restarts and starts sending from the top of the list again. It fails again part way through the list, and restarts. If the mail went out at night or when I can't be contacted, this just keeps repeating forever until somebody realizes it's gone crazy and notifies me, and can get to a place to log in to the server and stop it. Once it starts, it will not recover on its own. It appears that some random situation first puts it over the edge, but continually restarting the maillist ends up stressing the connection pool enough to make it feed on itself and never recover. When I stopped the server, I had about 1500 emails in the spool table (the original source email + all the individual ones I had sent). I just wiped these out of the db to recover. The recipient at the top of the list gets flooded. The last recipient in the list likely never got the email at all. Thanks again for all the help. Jerry -----Original Message----- From: Stefano Bagnara [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 11:15 AM To: James Users List Subject: Re: Mail List Mailet Infinite Loop on db failure JWM wrote: > If my proposal above for my own code sounds reasonable, then so be it. I > have no problem writing it. I just want to know if that is my only/best > solution for guaranteeing 100% that never more than 1 copy of the email is > sent. (I'll accept 0 or 1 copy being sent. The sender can resend if > necessary). This is not how SMTP works: SMTP grant the messages will be sent at least once. There's no way to be sure you send a message a single time in SMTP: the most common "hole" is in the time between the receiving server say it has accepted the message and the client acknowledge this fact. If anything happens in that moment the message is resent (by specification). Apart RFC consideratons you should write your own code to protect from this behaviour. Your solution seems acceptable given your specifications. BTW I didn't understand your exact scenario: I've had sql problems in past but I never had James looping with thousands of duplicated messages sent. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
