关于在后台线程中发送电子邮件,我应该了解哪些信息?网络平台
我有一个在后台运行的线程,当有东西唤醒它时,它将休眠并从数据库中提取数据。我正在使用 SmtpClient 使用谷歌应用程序发送电子邮件(代码如下)。
我想知道是否有什么我需要注意的?我计划一次仅发送一封电子邮件(注册或忘记密码电子邮件)。我有点担心会发生一些事情,比如无效的电子邮件锁定线程,因为我没有设置超时,或者谷歌应用程序碰巧完成并导致应用程序崩溃。我应该注意什么?我想问一下我应该如何测试?
var client = new SmtpClient("smtp.gmail.com", 587)
{
Credentials = new NetworkCredential(fromAddr, pass),
EnableSsl = true
};
MailMessage mail = new MailMessage(fromAddr, toAddr, subject, body);
mail.IsBodyHtml = true;
client.Send(mail);
I have a thread running in the background that will sleep and pull data from the database when something wakes it up. I am sending the emails using google apps using SmtpClient (code below).
I wanted to know if there is anything i be aware of? I plan to send only one email at a time (a registration or forgot password email). I am a little worried something can happen like an invalid email locking up the thread because i didnt set a timeout or maybe google apps happen to be done and causing the app to blow up. What should i be aware off? I should ask how i should test as well?
var client = new SmtpClient("smtp.gmail.com", 587)
{
Credentials = new NetworkCredential(fromAddr, pass),
EnableSsl = true
};
MailMessage mail = new MailMessage(fromAddr, toAddr, subject, body);
mail.IsBodyHtml = true;
client.Send(mail);
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果您使用的是 IIS。在您的服务器上安装 SMTP 并将所有邮件发送到本地主机。这样,如果电子邮件没有立即通过,SMTP 服务器会将电子邮件排队,而不是挂起您的应用程序。
您需要配置 SMTP 服务器以使用 gmail 作为智能主机。如果您需要有关如何配置的更多信息,请告诉我。
If you're using IIS. Install SMTP on your server an send all mail to localhost. That way if an email doesn't go through right away, the SMTP server will queue the email instead of hang your application.
You will need to configure the SMTP server to use gmail as a smarthost. If you need more information about how to configure this, let me know.
在代码中添加一个 try/catch 就可以了。在最坏的情况下,它最终会超时。它不会永远运行,Google 也不会永远保持连接打开(事实上,SMTP 在超时方面是相当无情的……如果你速度慢,它就会终止连接)。
进行测试时...使用不同的 gMail 帐户。此外,您可能还想检查每天发送电子邮件的限制。不确定 gMail 的号码是多少,但它们不仅仅让您发送您想发送的数量。
Add a try/catch to the code, and you are fine. It will, at worst, eventually timeout. It won't run forever, and Google won't keep the connection open forever (in fact SMTP is pretty unforgiving when it comes to timeouts... if you are slow, it will kill the connection).
When it comes to testing... use a different gMail account. Also you may want to check on your limit of sent emails per day. Not sure what gMail's number is but they don't just let you send how ever many you want to send.
我假设这是在 ASP.Net 下完成的,因为它是标签之一。
这个过程有多重要?如果您的环境允许,这可能是 Windows 服务的良好候选者,而不是 ASP.Net 运行时的一部分。
您提到过从数据库中提取数据并发送电子邮件。所有这些都不依赖于 ASP.Net。另外,服务可以为您提供更好的线程、测试、日志记录和异步选项。
如果您想坚持使用 ASP.Net 运行时,那么您还可以考虑 异步页面 如果你还没有的话。这将允许您生成多个邮件线程并让您的主页线程等待结果。您还可以设置一个超时值,该值允许您取消和记录卡住的线程。我怀疑设置和处理异步超时可以解决您的大部分担忧。该解决方案至少将使您的邮件发送脱离您的页面请求线程。
测试应该是直接的。您可以注册单独的谷歌帐户进行测试。
I am assuming this is being done under ASP.Net since it is one of the tags.
How important is this process? This may be a good candidate for a Windows Service rather than part of the ASP.Net runtime if your environment allows.
You've mentioned that you pull the data from the database and send the email. None of this relies on ASP.Net. Plus a service may give you better threading, testing, logging and async options.
If you want to stick with ASP.Net runtime, then you can also consider Asynchronous Pages if you haven't already. This will allow you to spawn several mail threads and have your main page thread wait for the results. You can also set a timeout value that will allow you to cancel and log stuck threads. Setting and handling an async timeout would take care of much of your worries I suspect. This solution will at least take your mail sending off your make page request thread.
Testing should be straight forward. You can register separate google accounts for testing.
您可以设置
SmtpClient
的Timeout
属性,然后处理Send
调用引发的任何异常。然后它不会锁定线程,尽管您必须根据您认为适当的方式处理异常的原因。You can set the
Timeout
property ofSmtpClient
, and then handle any exceptions thrown by theSend
call. Then it will not lock up the thread, though you will have to handle the cause of the exception as you deem appropriate.