Should I instantiate TIdSMTP each time email message is sent? [closed] - delphi

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
All Indy SMTP examples I have seen show TIdSMTP being instantiated at the start of the email send routine and freed at the end.
I have written an SMTP email sender prototype application, based upon Indy 10 components, that normally works with no issues. (It can send in the clear or via explicit or implicit TLS.) It instantiates TIdSMTP on startup and frees it on closing.
I have just had a situation where IdSMTP.Send threw an exception saying that SMTP was not connected. This would be unremarkable except for the fact that I have a test for IdSMTP.Connected, immediately prior to my IdSMTP.Send, that reported that SMTP was connected. My program could no longer be made to send emails because it thought it was connected but in reality it wasn't. The only solution was to restart the program. When testing of this prototype application is completed the code will be incorporated into a server service that cannot just be restarted to fix this sort of problem.
The problem could have been avoided or, at least, worked around if I had instantiated my TIdSMTP class within my email send procedure; in the unlikely event of this re-occurring the IdSMTP object would be freed at the end of the procedure and re-instantiated the next time it gets called.
The reason I didn't architect my solution as in the examples was that re-instantiation of TIdSMTP for each email send also requires that the IdSMTP object reconnect to the email server for each send. This can be a very slow process - of the order of 5 to 10 seconds for external email servers - and this overhead can be avoided by not re-instantiating TIdSMTP each time.
So my question is: is this (or similar issues) the reason why all examples show re-instantiation each time? Or, is it simply to show a complete, contained example? The latter was how I interpreted it.
If you have experience with the pros and cons of this issue, please provide your opinions, and thoughts.
If there exists a definitive best practice, that would useful to hear about too.

Answer 1

All Indy SMTP examples I have seen show TIdSMTP being instantiated at the start of the email send routine and freed at the end.
They are just examples. Obviously production code can be more complex. You can reuse a single TIdSMTP object multiple times.
I have a test for IdSMTP.Connected, immediately prior to my IdSMTP.Send, that reported that SMTP was connected.
Let Send() fail and raise an exception if the connection is not available. Indy uses exceptions for error reporting, so make use of them, don't avoid them. Connected() can report a false positive. If the IOHandler.InputBuffer has unread data in it, Connected() will return true, even if the underlying socket is closed. This is by design. Don't rely on Connected() to drive your logic.
My program could no longer be made to send emails because it thought it was connected but in reality it wasn't.
After Connect() succeeds, if you get any exception that is not derived from EIdRFCReply, you should Disconnect() the connection and Clear() the InputBuffer (if there is still an IOHandler assigned - Disconnect() will free it if it was created internally by Connect()) before calling Connect() again. Connect() raises an exception if Connected() returns true, so you have to manually clear the condition that causes that (unread data) if an unexpected error occurs.
Try
If not SMTP.Connected then SMTP.Connect;
...
Except
On E: EIdRFCReply do
Begin
// an SMTP command failed, but the connection is still stable
...
End;
On E: Exception do
Begin
SMTP.Disconnect(False);
If SMTP.IOHandler <> nil then SMTP.IOHandler.InputBuffer.Clear;
...
End;
End;

Answer 2

In general, you should keep connections to the outside for as short a time as possible. I assume that this program/service doesn't send emails 24h/7d continously, but in response to some external event (a timer or other event that triggers "now it is time to send"), and then it sends one (or more) emails at that point.
The way I would code this is to instantiate the TIdSmtp at the start of this event and then free it at the end. This way, you would have a freshly instantiated connection to the outside every time.
If your program only sends a single email on every event, then you could perhaps code it such that if the sending fails, then signal that on the next event, you should re-instantiate the TIdSmtp variable, something along these lines:
PROCEDURE SendMsg(...)
BEGIN
IF NOT Assigned(SMTP) THEN SMTP:=TIdSmtp.Create(NIL);
TRY
... Your code to send one or more emails ...
EXCEPT
FreeAndNIL(SMTP);
... Perhaps Re-Raise exception, if outer layer needs to know ...
END
END;
This way, the SendMsg routine is self-restarting in case of error. Of course, some more error checking (what kind of exception was caught) would be advisable, but I expect you get the general idea...