Client does not reconnect on network failure, even with KeepAlive
vjeantet opened this issue · 5 comments
I had a smtp connexion OK (with keepalive), when suddently the remote server closed it.
Since this event no mail were sent, event if the remote server is back online.
Here is the log i have each time i send a mail since the event.
write tcp 127.0.0.1:60591->127.0.0.1:25: wsasend: An existing connection was forcibly closed by the remote host.
The only way to get my mails sent again, was by killing/starting my app.
You can easily reproduce this case with mailHog, by activating "JIM" with -invite-jim -jim-disconnect "1"
Keep alive not close the connection to SMTP server after send the email, but you need to do a NOOP to avoid SMTP server close the connection by inactivity. See #13.
Hello @xhit, In my case the smtp server crashed (or a network packet loss)
I expected the smtpClient to try to rebuild the connection by itself or return an specific error so i could handle to rebuild the smtpClient.
As of today, even is the server comes back online, the SmtpClient try to send mails throught the old broken connection.
It's the expected behavior. This package not auto reconnect when SMTP was disconnected by network error or inactivity.
This need to be handle by developer.
I have a big project that handle that. I will create a example code in next hours with this implementation.
This it's the logic, and using the NOOP with this package:
- connect to SMTP server with keep alive true
- create a goroutine that send a NOOP every 10 seconds if last email was sent after that time only
- send the email
If email is ok, the NOOP timeout variable need to be reset to 0. If error, then reconnect.
Note that a NOOP need to be sent only if SMTP is not in use.
NOOP keep the SMTP connection alive to avoid a disconnection by inactivity and also to check if connection it's available because return same error you have, so if happens you need to reconnect.
You need to reconnect only if error is not an SMTP error code. You can unwrap the error to get the code (3 digits number).
The project using this package is currently in production sending 1000 emails/seconds (transactions, not spam) without issues.
Maybe this operation should be done in package without dev intervention. I don't know if devs like this type of magic.
thanks you, i get it !
Closed because is not an issue, but in future can be a new feature.