サーバーWebアプリは、RESTAPIリクエストによってリクエストされたジョブを処理します。
理想的には、サーバーがジョブ中に停止した場合（つまり、プラグが抜かれた場合）、ジョブは起動時に再開または再開する必要があります。
これらのジョブを処理する非常に便利な方法は、Java 5の並行ユーティリティクラスのいくつかを使用する別のスレッドです。唯一の問題は、失敗した場合、ジョブの詳細を書き留めて、これらの詳細を読み取るプロセスを作成する必要があることです。起動時にジョブを再開します。これはやるのが面倒なようです。
別のアプローチは、ユーザーがリクエストを行うキューを使用し、キューに書き込み、キューから読み取り、ジョブを実行し、ジョブが完了したときにのみメッセージを削除することです。これにより、サーバーは起動時にキューから読み取り、プロセスを再開するだけなので、起動時にジョブを簡単に再開できます。
このシナリオへのより良いアプローチはありますか？
Quartz（フェイルオーバー機能付き）を使用してジョブを管理します。
PS：私は間違っていることを望んでいますが、あなたの最後の質問を読んだことで、あなたは過度に複雑な、または概念的に間違った何かを構築していると感じています。建築の匂いが多すぎます。
RESTを指定したことを考えると、明らかに、要求を行い、結果を要求するクライアントがあります。クライアント自身で完了したかどうかを判断する責任を負わないのはなぜですか。
たとえば、クライアントがリクエストを行います。結果が戻ってきたら、すべてうまくいきます。ただし、クライアントがサーバーが終了したことを検出した場合（HTTP接続の早期切断を介して）、サーバーはバックオフして後で再試行できます。必要に応じて、さまざまな再試行戦略を実装できます（たとえば、別のホストで再試行したり、「n」回の再試行後にあきらめたりするなど）。
このようにして、クライアントは必要なものについての知識を維持し（おそらく、とにかく行う必要があるため）、サーバーはステートレスであり、管理がはるかに簡単です。