JMSの代替ですか？ http reqsからのメールをデカップリングするためのもの

Question

私たちは、さまざまなことを行い、特定のアクションに応じてユーザーに電子メールを送信するWebアプリケーションを持っています。 SMTPサーバーやバックログに問題がある場合に備えて、実際に電子メールを送信しないようにhttpリクエストスレッドを切り離したいと思っています。これまで私はJMSを使用していましたが、問題はありませんでした。しかし、現時点では、私たちがJMSをやっているWebアプリケーションのために、ちょうど（セットアップなどの面で）ちょっとした殺しを感じています。 理想的には、私はインプロセス（JVM/Tomcat）で実行できるものが好きですが、サーブレットコンテキストがアンロードされると、キュー内の保留中のアイテムはすべてdisk/dbにスワップされます。私はもちろん、メモリQを含む何かを一緒にコーディングすることもできますが、私はオープンソースプロジェクトのメリットを得るために探しています。

JMSが本当に私たちの単純な要件に適合するsomethignについて知っている答えであれば。 ありがとう

Answer 1

私はこのためにJMSが不当であることに同意します。

電子メールは、別のスレッド（つまり、要求処理スレッドとは別）で送信することができます。慎重に念頭に置いておいていただきたいのは、アプリが何らかのトラフィックを受け取った場合、リソースプールの問題を避けるためにスレッドプールを使用することです。 java.util.concurrentパッケージには、スレッドプール用の素晴らしいものがいくつかあります。

Answer 2

スケジューラを使用できます。 Quartzをご覧ください。

アイデアは、ジョブを定期的に開始するようにスケジュールすることです。すべてのリクエストはどこかに保持する必要があります。スケジュールされたジョブはそれらを読み取り、処理します。 2つの後続ジョブの間隔を必要に応じて定義する必要があります。

これはおすすめの方法です。本格的なアプリケーションサーバーでは、Java EEタイマーを提供していますが、Tomcatでは使用できません。しかし、クォーツは問題ありません。あなた自身のスレッドを開始することを避けることができます。これは、状況によっては（アプリケーションのアップデートなどで）混乱の原因となります。

Answer 3

私は同様の目的でJMSを使用しています。 JMSを使用するための我々の理由：

• 我々はすでに何か他のもののためにJMSサーバを持っていた（ので、それだけで新しいキューを追加しました）
• 我々は我々のアプリケーションは、処理プロセスから切り離すことが望んでいた、いずれかの側でエラーので、彼らの側にとどまるだろう
• アプリは、キューにメッセージをドロップし、コミットして、続行する可能性があります。メッセージを持続させる方法、クラッシュ後にやり直す方法などを心配する必要はありません。JMSはすべてそれを行います。

Answer 4

うわー、この問題はたくさん起こります。 CommonJ WorkManagagerはあなたが探しているものです。 Tomcatの実装はhereです。 Java EE環境でスレッドを安全に作成することができますが、JMSを使用するよりもはるかに軽量です（明らかにうまくいくでしょう）。

Answer 5

アプリは「時々」ユーザーに電子メールを送信すると、あなたは大量のメールについて話しているようには聞こえません。

sendmail recipient@domain.com

、そして得られたプロセスののgetOutputStream（）にメッセージをダンプ：迅速かつ汚いソリューションは、ちょうどRuntime.getRuntime().exec()になります。その後、それはsendmailの問題です。

図では、サーバー上で利用可能なsendmailがあるかどうかを確認するために1分、テストする場合は約15分、sendmailを見つけた場合はインストールすることはありません。電子メールヘッダーを正しく構成するには数分（簡単 - here are some examples）、完了です。

希望します...

Answer 6

私はこの場合もスプリングの統合はうまくいくと思います。

http://www.springsource.org/spring-integration

Answer 7

超えJMS、短いメッセージのために、あなたはまた、Amazon Simple Queue Service（SQS）を使用することができます。 あなたはそれも残念だと思うかもしれませんが、メンテナンスが最小限で済み、うまくスケーリングされ、超高可用性があり、それほどコストがかからないという事実を考慮してください。 新しいキューを作成するなどの費用はかかりません。またはアカウントを持つ。私が思い出す限り、それは純粋にあなたが行う操作の数（メッセージの送信、ポーリング/取得）に基づいています。

本当にメッセージサイズは主な制限です（分散した性質などにより注文を保証していないようなものもあります）。それはそのまま動作するかもしれません。または、より大きなメッセージの場合は、関連するAWSサービスs3を使用して実際の本文を格納し、ヘッダーをSQSに渡すだけです。