Dealing with SMTP Timing Out

We have been getting SMTP timeouts recently in our "Send Email" steps for some reason. I know you probably can't help us with the root cause of those timeouts, but I have a couple questions about how to deal with them cleanly.

Here is the exception we get:

Initializing action...
    Initialization complete. Executing...
    Preparing Email Message
    An unhandled exception occurred while executing this action: System.Net.Mail.SmtpException: The operation has timed out.
       at System.Net.Mail.SmtpClient.Send(MailMessage message)
       at Inedo.BuildMaster.Extensibility.Actions.General.SendEmailAction.Execute()
       at Inedo.BuildMaster.Extensibility.Actions.ActionBase.ExecuteInternal(IActionExecutionContext context, ExtensionConfigurerBase extensionConfigurer, Boolean resumeNextOnError, Boolean logErrorsAsWarnings)

Deployments are failing on the Send Email step most of the time (but not always). However, the emails are still being sent -- the failure reported by BuildMaster is not really correct. So that's one area where I need to understand what is really happening -- the email is, in fact, being sent. It's just that BuildMaster thinks there is a timeout and then it fails the step. What is going on there?

To handle this, I thought I would go to the advanced options of the Send Email step and set the Timeout to 30 seconds, thinking it would then wait 30 seconds before "failing". This didn't seem to have any effect. It would still "fail" after like 15 seconds. Does that Timeout value not work the way I expect?

I also tried setting the Retry Count to 3, thinking that it would at least take 3 "timeouts" to cause the step to fail. It merely resulted in two failures and then on the third attempt, a success. Everyone got three emails, though.

Any advice on how to handle this? We are using Exchange.

Product: BuildMaster
Version: 4.1.6

I'm not sure why you'd get a timeout while sending a message, that's usually a pretty quick transaction... but, in any case we are just using the standard SMTP libraries in .NET, so hopefully you'll be able to figure the root cause -- let us know what you find!

Regarding the Timeout... that's more used by the executor. Once the timeout is reached, the executor will attempt to cancel the action. In this case, the Timeout value is not being passed to the SMTP Client object, which is why it's failing after waiting the default amount of time (which, we set to 15 seconds as you discovered).

We will have the SmtpTimeout be inherited from the action timeout in a future release (BM-1472)... though it probably won't solve the underlying problem. Can't imagine something's actually taking 15 seconds!

Ok, so the time out value is just a way to say to give up (fail) after X seconds. That makes sense. I found documentation of these settings at http://inedo.com/support/documentation/buildmaster/deployment-automation/deployment-plans/actions.

The funny thing is that even when BuildMaster fails the step due to a timeout, the emails are being sent... immediately. So is BuildMaster waiting for acknowledgement from Exchange that isn't coming back soon enough?

These are really tiny emails with a small attachment, so I know the root cause is on our end and has to do with server/network latency or something to that effect.

As a workaround, I set these actions to log errors as warnings so it won't fail the execution. These emails are always the very last step of a deployment so even if they "fail" it's fine.

I'm not really sure how things work behind the scenes. I mean, our code is quite simple/straightforward... we just use an SmtpClient to send a MailMessage, and pass in configuration from the "SMTP Settings" under Admin.

You may want to enable SMTP logging on your SMTP server? You can always test the SMTP commands with Telnet as well --- http://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/

We are having an issue with Send Email now as well. We are getting the same SMTP error, but the email are not sending.

System.Net.Mail.SmtpException: The operation has timed out.
It seems that the Send Email Timeout (seconds) configuration isn't being respected. It was set to blank, which should be infinite, however it was timing out very quickly. I set the timeout to 600 seconds, but the emails are still failing to send (almost immediately).
I then set the retry count up high, which is being respected, but the email are still timing out. I eventually set the retry limit to 50, just to see if the email would send, but they are still failing.

The send test email function in the BM configuration section is successfully sending an email, albeit the pages post seems to take about 10 seconds. I'd say the average time for the SendEmail step to fail (with timeout) is about 0.7 seconds, even though timeout was set to infinite, then 30 seconds, then 10 minutes.

Whoopsies, I screwed up that block quote, can't edit post so reposting correctly.

We are having an issue with Send Email now as well. We are getting the same SMTP error, but the email are not sending.

System.Net.Mail.SmtpException: The operation has timed out.

It seems that the Send Email Timeout (seconds) configuration isn't being respected. It was set to blank, which should be infinite, however it was timing out very quickly. I set the timeout to 600 seconds, but the emails are still failing to send (almost immediately).
I then set the retry count up high, which is being respected, but the email are still timing out. I eventually set the retry limit to 50, just to see if the email would send, but they are still failing.

The send test email function in the BM configuration section is successfully sending an email, albeit the pages post seems to take about 10 seconds. I'd say the average time for the SendEmail step to fail (with timeout) is about 0.7 seconds, even though timeout was set to infinite, then 30 seconds, then 10 minutes.

This original post is really old and refers to an old version of BUildMaster (v4); I'm not sure what version you're using, etc.

Can you submit this as a new question so we can more easily try to address / reproduce / investigate it?