Clean disconnect when buffer done?

[DavidKelleySCSC]

If there a design reason the socket to the remote SMTP node is not closed when the buffer is emptied?
It appear to just leaves it open and after a bit of time the other side drops it.

readyRead unknown state "421 4.4.2 xxxhiddenxxx.com Error: timeout exceeded\r\n"

[dantti]

the reason is due performance, you don't want to keep reopenning the SMTP connection, doing it's slow handshake everytime you need to send an email. The other side usually drops the connection, but for heavy traffic it won't close.

[DavidKelleySCSC]

In our use case there might be 10~100 emails once every few hours at most, but the key issue is a burst followed by none. While it seems harmless to let it time out, is this practice considered 'bad form' to wait until the other end drops it? I have little experience with only a few SMTP servers in this regard. I can of course just do a close on the socket when the buffer reaches zero, probably a good solution for this case.

[dantti]

is this practice considered 'bad form' to wait until the other end drops it?

AFAIK no, specially since you are usually using your own/paid mail server to send out emails I guess it would be ok for the server to be ready to send mails right away.

[DavidKelleySCSC]

Like to reopen this and ask how (code fragment please) and where to best close the socket once the pending work que reaches zero.

We seem to have an periodic issue where a new message is being created and enqueued to be sent at just the moment in time the server connection timeout / disconnect occurs- resulting in lost mail. It only seems to occur during heavy loading, but just at about 60 or 90 second mark (the timeout point for the two machines we use).

[dantti]

do you happen to get an error due it being closed?

[DavidKelleySCSC]

I have to dig a bit into the logs to find out. On the surface, it simply does not send, losing that posting. The next posting works fine. [I must say the lambda aspect of this code, while both clever and the future, blocks our normal error logging, this old dog has some learning to do] I believe below here is a relevant fragment of the debug log we keep. And to repeat, I think if we were to shut down the connection rather than let the other side time out, we would be okay.

.... end of last send...
Got response: 250 2.0.0 Ok: queued as 23B1121945
# MAIL FINISHED Code:250 Msg Sent Ok with 0 more to go, 0

ProcessNextMail( Pending: 0 )
This batch required:: 755 mSec of clock time, now moving to sleep mode (mail log 3.87 KB chars).
ReadyRead: 0 bytes
ProcessNextMail( Pending: 1 )
Sending MAIL commands: Pipelining, Cmd Count:4
MAIL FROM:<xxx>
   RCPT TO:<xxx>
   RCPT TO:<xxx>
   DATA
Reply Codes: 250 250 250 354
Message #295 [xxx Test message 295], enqueue time 2 mSec.


ReadyRead: 79 bytes
Got response: 250 2.1.0 Ok
Got response: 250 2.1.5 Ok
Got response: 250 2.1.5 Ok
Got response: 354 End data with .
Mail sent
ReadyRead: 0 bytes
ReadyRead: 36 bytes
Got response: 250 2.0.0 Ok: queued as CB9F423D58
# MAIL FINISHED Code:250 Msg Sent Ok with 0 more to go, 0

ProcessNextMail( Pending: 0 )
This batch required:: 280 mSec of clock time, now moving to sleep mode (mail log 4.58 KB chars).
ReadyRead: 0 bytes
ProcessNextMail( Pending: 1 )
Sending MAIL commands: Pipelining, Cmd Count:4
MAIL FROM:<xxx>
   RCPT TO:<xxx>
   RCPT TO:<xxx>
   DATA
Reply Codes: 250 250 250 354
Message #296 [xxx Test message 296], enqueue time 2 mSec.


ReadyRead: 79 bytes
Got response: 250 2.1.0 Ok
Got response: 250 2.1.5 Ok
Got response: 250 2.1.5 Ok
Got response: 354 End data with .
Mail sent
ReadyRead: 0 bytes
ReadyRead: 36 bytes
Got response: 250 2.0.0 Ok: queued as BA36323BD4
# MAIL FINISHED Code:250 Msg Sent Ok with 0 more to go, 0

ProcessNextMail( Pending: 0 )
This batch required:: 282 mSec of clock time, now moving to sleep mode (mail log 5.29 KB chars).
ReadyRead: 0 bytes
ReadyRead: 67 bytes
readyRead unknown state: 421 4.4.2 smtp5.relayxxx.com Error: timeout exceeded , 12
ReadyRead: 0 bytes
SocketError: 1