さまざまなことを行い、特定のアクションに応じてユーザーにメールを送信する Web アプリケーションがあります。SMTP サーバーまたはバックログに問題が発生した場合に備えて、http 要求スレッドを実際に電子メールを送信することから切り離したいと考えています。過去に、私はこれに JMS を使用しましたが、問題はありませんでした。ただし、現時点では、JMS を実行している Web アプリケーションについては、(セットアップなどの点で) ちょっとやり過ぎだと感じており、他にどのような代替案があるのか疑問に思っていました。理想的には、インプロセスで実行できるもの (JVM/Tomcat) が好きですが、サーブレット コンテキストがアンロードされると、キュー内の保留中のアイテムが disk/db にスワップされます。もちろん、インメモリ Q を含む何かを一緒にコーディングすることもできますが、オープンソース プロジェクトの利点を得たいと考えているので、何かあるとしたら何か疑問に思っています。
JMS が本当に答えである場合、単純な要件に適合するものを知っている人は誰もいません。ありがとう
私はJMSを似たようなものに使用しています。JMSを使用する理由：
この場合も春の統合がうまくいくと思います。
スケジューラを使用できます。Quartzをご覧ください。
アイデアは、ジョブを定期的に開始するようにスケジュールすることです。すべてのリクエストは、どこかに永続化する必要があります。スケジュールされたジョブはそれらを読み取り、処理します。必要に応じて、後続の 2 つのジョブ間の間隔を定義する必要があります。
これは、物事を行うための推奨される方法です。本格的なアプリケーション サーバーは、このために Java EE タイマーを提供しますが、これらは Tomcat では利用できません。ただし、Quartz は問題なく、独自のスレッドを開始することを避けることができます。これにより、状況によっては混乱が生じることがあります (アプリケーションの更新など)。
JMS を超えて、短いメッセージにはAmazon Simple Queue Service (SQS)も使用できます。やり過ぎだと思うかもしれませんが、必要なメンテナンスが最小限であり、適切にスケーリングされ、非常に高い可用性があり、それほどコストがかからないという事実を考慮してください。新しいキューなどを作成するための費用はかかりません。またはアカウントを持っています。私が思い出す限り、それは純粋にあなたが行う操作（メッセージの送信、ポーリング/取得）の数に基づいています。
主な制限は実際にはメッセージのサイズです (分散された性質のために順序を保証しないなど、他にもあります)。しかし、それはそのまま機能する可能性があります。または、より大きなメッセージの場合は、関連する AWS サービス s3 を使用して実際の本文を保存し、SQS を介してヘッダーを渡すだけです。
アプリが「時々」ユーザーにメールを送信すると言うので、大量のメールについて話しているようには聞こえません。迅速で汚い解決策は、次のことですRuntime.getRuntime().exec()。
sendmail recipient@domain.com
結果のプロセスのgetOutputStream（）にメッセージをダンプします。その後、sendmailの問題です。
サーバーでsendmailが利用可能かどうかを確認するために、1分を計算します。利用できる場合は、テストをまとめるのに約15分かかります。また、sendmailが見つかった場合は、何もインストールしません。電子メールヘッダーを適切に作成するためにさらに数分（簡単-ここにいくつかの例があります）、これで完了です。
お役に立てれば...
JMS がこれに対してやり過ぎであることに同意します。
別のスレッド (つまり、要求処理スレッドとは別) で電子メールを送信できます。注意すべき唯一のことは、アプリがなんらかの種類のトラフィックを取得する場合、リソースの枯渇の問題を回避するためにスレッド プールを使用することをお勧めします。このjava.util.concurrentパッケージには、スレッドプール用の優れた機能がいくつか含まれています。