私はこのようにアプローチします。
このユース ケースのハンマーは、Java Watch Service、サーブレット、JMS キュー、およびバッチ サービスです。
まず、Watch サービスは、ファイル システムの監視を処理する Java 7 の移行先です。
Watch Service の実装を作成し、それをスレッドで実行します。
あなたが尋ねるスレッドはどこで実行されますか?
公式には、おそらくこれには JCA を使用する必要があります。しかし、JCA は非常に扱いにくく、十分に活用されていないため、文書化も不十分です。確かな例はありますが、Java EE スタックの一般的なテクノロジではありません。
もう 1 つの場所は、非同期のセッション Bean 呼び出しです。これらが長命の呼び出しではないことを示唆するものは何もありません。@Startup を使用して @Singleton セッション Bean を立ち上げ、@PostConstruct メソッドから async メソッドを呼び出して、放すことができます。次に、@PreDestroy で長時間実行されているメソッドを停止するように通知し、完全にシャットダウンできるようにします。Hoyle によれば、これはすべて仕様どおりで、移植可能である必要があります。
3 番目は ServletContextListener です。これは、Java EE 6 より前に、コードをアプリケーションのライフサイクルに結び付けるための場所です。ここでは、contextInitialized メソッドで自分でスレッドを作成し、contextDestroyed メソッドで破棄します。
ここでスレッドを作成することは「あまり定義されていません」ですが、私は何年もそれを行ってきましたが、問題は一度もありませんでした.
サービスを実行するようになったので、サービス (IMHO) は 2 つのことを行います。
1）新しいファイルがディレクトリに到着したことを感知し、到着すると、ファイルを並列の「処理」ディレクトリに移動（mv、名前変更）します。これは、ファイルが受信から処理に移行したこと、ファイルが進行中の作業であることを示しているためです。バックエンドが何をしていると考えているかに関係なく、ディレクトリのリストから明らかです。システムはファイルの途中でダウンする可能性があることに注意してください。
2) 移動したら、ファイル名とその他のメタデータを JMS キューにポストし、MDB にバッチ ジョブをツールアップさせます。
JMS キューを追加する理由 パーティーにいくつかの機能をもたらします。まず、EJB が好むハッピー トランザクション コンテキストの「外側」から内側へのものを取得するための優れた方法です。第二に、それはトランザクションです。ETL のユース ケースによっては、MDB でジョブを直接処理することができます。そうすることで、処理が完了するまで (そしてファイルが削除されるか、「処理中」ディレクトリから移動されるまで)、キューからのメッセージを確認しないだけです。理想的な世界では、メッセージ キューには、処理ディレクトリ内のファイルと一致するメッセージがあります。処理が完了すると、メソッドが返され、メッセージ フェッチが「コミット」され、完了です。システムがクラッシュした場合、これは自動的に最初からやり直されます (メッセージはまだキューにあり、削除されていないため)。
MDB は、そのインスタンスを構成することにより、同時ジョブの数も制御できます。10 個のインスタンスを構成します。同時に処理できるのは 10 個のファイルのみです。しかし、これは少し単純すぎたり、粗すぎたりする可能性があります。たとえば、優先順位はありません (先着順)。しかし、それはあなたのために働くかもしれません。
いずれにせよ、MDB はシステムへの優れたゲートウェイです。それぞれが独自の小さなトランザクション コンテキストから始まるからです。長時間実行されるサーブレット スレッドや長時間実行される非同期スレッドとは異なります。サーブレット スレッドのトランザクション ステータスが疑わしい (存在する場合) 場合、実行時間の長いスレッドは @Startup メソッドからその状態を継承し、存続期間中保持します。MDB は毎回新しいものを取得します。これの多くは、新しいトランザクションでメソッドを呼び出すことでごまかすことができます。
しかし、私はMDBの境界が好きです。ファイル名のバッチ エントリを作成することがすべてのタスクである場合でも、MDB は優れたゲートキーパーです。
そして、それはほとんどそれです。
重要な部分は、善良な市民であり、アプリケーションのライフサイクルに適切に結び付けられたスレッドを分解し、さまざまなコンポーネントでのトランザクションの状態を理解し、すべての可動部分がどのように組み合わされるかを理解することです。
@Startup 手法を使用する場合は、必ずセッション Bean の別のインスタンスを注入して非同期メソッドを呼び出してください。それ以外の場合、呼び出しは非同期ではなくローカル呼び出しになります。サーバーがハングアップして起動しない理由を不思議に思うでしょう。すべての EJB アノテーションは、注入されたプロキシまたは検索されたプロキシを介して呼び出された場合にのみ機能します。
楽しんで、共有して、楽しんでください。
質問への補遺：
外部プロセスに監視サービスを管理させることには、実際には何の価値もありません。サーバーのライフサイクルに結び付けられたものは、保守が容易です。2つのことが思い浮かびます。サーバーがダウンした場合、ファイルはサーバーが再起動されるまでファイル システムに蓄積されるため、データが失われることはありません。外部サービスがある場合は、メッセージをデッド サーバーに送信するか、アプリケーション サーバーとは別に JMS サーバーをステージングおよび管理する必要があります。その場合、アプリ サーバーだけでなく、監視サービス、JMS サーバー、およびアプリ サーバーの 3 つのプロセスを管理する必要があります。
とにかく外部サービスを使用することに決めた場合、サーバー上のJAX-RS RESTサービスに単純なメッセージを投稿する単純なJava SEアプリ、または単純なサーブレットでさえ、はるかに維持しやすいという他のポスターに同意します、アプリ クライアントよりもステージングして展開します。そのようにすれば、監視サービスをまったく別のものに書くことができます。
しかし、サーバーは (表向きは) ファイルを使用してファイル システムに直接アクセスできるため、このサービスをコンテナーの外で中断する動機は実際にはありません。キット全体を EAR に入れて使用します。フラットにするだけで管理が楽になります。