排队或不排队使用Java邮件

Question

该方案是从Web请求（以及将来可能与其他邮件相关的任务）向用户发送密码重置邮件。

我带到桌子排队的参数：

• 我认为应尽快处理网络请求

• 将发送操作与请求分离，更容易实现邮件系统的外部化（如果将来需要）

我认识到反对排队的论据：

• 如果在发送消息时出现问题，则用户无法获得反馈

在这次讨论中还有哪些论点？对于那些赞成排队的人，你会如何实现队列？预定行动？无限的出列任务（当然还有间隔）？

谢谢！

Answer 1

您绝对不希望同步发送，因为邮件服务器可能很慢。

发送JMS消息并使用MDB发送电子邮件。

Answer 2

我建议您将实际发送的邮件与应用业务逻辑分开。这样做是不同寻常的。由于以下原因，使用JMS或至少不同的线程发送此类通知邮件：

1. 它绝对是可选的任务。使用它阻止App服务器不是一个好主意。
2. 发送邮件可能会耗费大量时间。 即使您使用自己的内部邮件服务器，该服务器位于托管您的应用程序的服务器附近。 SMTP会话由交换请求/响应而不仅仅是一个呼叫组成。 （这就是为什么引入Pipelining的原因）
3. 不要将邮件发送视为交易操作。 当目标SMTP服务器回复250 OK作为DATA命令的响应时 - 它只对此邮件负责。 当链中的后续服务器无法发送邮件（阅读有关DSN）时，交付可能会失败。 这意味着如果后续服务器失败，用户将无法获得任何反馈。

Answer 3

在Java EE 6+场景中，您可以在EJB方法中使用@Asynchronous注释。它返回Future<V>。所以你可以继续proccesing并稍后询问任务结束，而它在另一个线程中执行。 因此，您可以快速接受大量请求，将发送操作与请求分离，您可以获得反馈。 http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html

Answer 4

您可能认为应该尽快为请求提供服务，但用户呢？他怎么想？

用户需要重置密码。他不在乎需要多长时间。如果他无法完成该请求，他根本无法做任何事情。

不要排队。

Answer 5

我想你应该去排队。因为它有助于提高性能并检查密码重置请求是否来自正确的来源。

所以你可以使用Map进行队列实现。因为在地图中你可以使用电子邮件ID作为密钥和唯一的请求引用作为值。并且应该在一段时间内删除此地图元素。

对于快速电子邮件服务，您可以创建一个简单的线程类，通过在其中传递一些数据参数来发送电子邮件并启动新线程。并且这些线程将由Web容器自动管理。