2

This issue has left me stumped. This question may need to be migrated to Server Fault, but there is a programming component, so I figured I'd start there. Also, our infrastructure team ardently believes everything is fine on their end, but that doesn't always mean anything.

Anyways, I've got a simple GET-POST-Redirect action that sends two separate emails using the Postal nuget package, before redirecting to a success page -- pretty basic stuff. The action is async, and I'm using await email.SendAsync() from the Postal API.

When the form is submitted, the first email comes into my inbox instantaneously, but the code hangs on that await email.SendAsync() line for a good 15-20 seconds before it moves on to the next line (confirmed in debugger). Then, it gets to sending the second email, which again comes into my inbox instantaneously and again the code hangs on that line, regardless of the successful send, for 15-20 seconds before moving on to the line with the redirect. In production, this delay after sending the email, combined for the two emails, causes the connection to reset before the redirect response can be sent. Sure, I could just up the page timeout, but that doesn't really fix the problem as the user still ends up with a minute long delay before getting a response.

I've also tried sending the emails synchronously with just email.Send(), but the same behavior occurs. I've looked through the source for Postal, and although it does some custom wrappings around SMTPClient to send asynchronous email, there's virtually nothing other than standard old C# email sending with the synchronous Send method.

It's also not bound to the server where the site is running, as I can see the same behavior in both production and when debugging locally (both connecting to the same production Exchange server, though).

It's acting like it's waiting for the Exchange server to send some sort of "finished" response, but from what I know about SMTP, it doesn't work like that. It should just send the email to the SMTP server and continue merrily along, trusting that the SMTP server will actually do what it's supposed to do.

Any ideas would be greatly appreciated, because I'm not even sure how to continue debugging this at this point. What else could I test or try?

UPDATE

Thanks to @MichaelEvanchik's suggestion to try out Wireshark, I was able to clearly see that there's actually a 30 second delay caused by the Exchange server. It receives the last bit of the email to be sent and then 30 seconds later finally responds to the client with "Successfully queued for delivery". It's at this point that the client finally QUITs and the code resumes. So, I'm kicking it back to infrastructure.

UPDATE #2

So, apparently there was actually a 30 second delay put on the connector to allow for confirmation that the email had truly been sent and not just queued for delivery. Personally, I think that kind of defeats the point of "queued for delivery" in the first place, but regardless, I don't need confirmation that it's actually been sent, just that it was received by the Exchange server, so infrastructure is removing the delay.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444

1 Answers1

0

Wireshark might shed some clues. =]

That is how to continue to debug, and will show you everything that is going on from http server to SMTP.

Derek
  • 952
  • 3
  • 13
  • 34
MichaelEvanchik
  • 1,748
  • 1
  • 13
  • 23
  • I didn't downvote you, but if I had to guess at why someone else did, it would be that your original answer was pretty terse. Even your edited answer isn't very helpful. I'm competent enough to lookup Wireshark and figure out how to use it on my own, but others who might have wrote this question and others who may view this in the future may not be. A good answer would provide much more detail and maybe some basic usage. Food for thought before you get angry at people for downvoting you. – Chris Pratt Nov 05 '13 at 21:02
  • your write up seems like you did so much and did the right stuff, I see it as the best solution, next I will just ask for wireshark dump files – MichaelEvanchik Nov 05 '13 at 21:30
  • 2
    Don't get me wrong; it's a good suggestion, and I'm looking into Wireshark as we speak. My only point was that while your answer is a great suggestion, it's not instructive. Like I said, it doesn't bother me, but I'm confident enough in my abilities to figure Wireshark out on my own. However, to someone less confident or more green to development, your answer might as well be "create a unified theory of everything". It's all about perspective, and StackOverflow encourages catering to the least among us, rather than expecting everyone to automatically understand. – Chris Pratt Nov 05 '13 at 22:49
  • From my personal experience have forwarded the same instruction above only to get thanks Michael! it showed me here and here whats the problem instantly. I cant assume he knows how to packet sniff. if I did that wouldn't be fair. Im an expert at wireshark and I live and die with it. I have even gone as far as reverse engineer protocols just to prove it was a vendor issue. so shoot me for being a cheerleader and no spot to put a comment only answers and could not tell my demeanor in my response if your calling my response snyde that's for sure as I am a happy person – MichaelEvanchik Nov 07 '13 at 16:25
  • chris glad you found the answer, like I said, it looks like you did everything YOU could. Your answer would have come from 2 places somebody who actually has had this problem outlined above or watch the traffic. I was going to suggest making a simple socket SMTP class so you can close the socket your self and send very simple SMTP commands but your wireshark work beat me to it. but if they could change the timeout that would be a way around it ... QUIT and socket.Close(); – MichaelEvanchik Nov 07 '13 at 16:36