問題タブ [job-scheduling]

MySQL をジョブ キューとして使用したいと考えています。複数のマシンがジョブを生成および消費します。ジョブをスケジュールする必要があります。毎時間実行されるものもあれば、毎日実行されるものもあります。

それはかなり簡単に思えます: 各ジョブに「nextFireTime」列があり、ワーカー マシンに nextFireTime でジョブを検索させ、レコードのステータスを「inProcess」に変更し、ジョブが終了したら nextFireTime を更新します。

問題は、労働者が静かに死ぬときに発生します。nextFireTime を更新したり、ステータスを「idle」に戻したりすることはできません。

残念ながら、ジョブは長時間実行される可能性があるため、inProcess が長すぎるジョブを探すリーパー スレッドはオプションではありません。機能するタイムアウト値はありません。

信頼性の低いワーカー マシンを適切に処理する設計パターンを提案できる人はいますか?

1つのUIに複数の連続したジョブを表示するにはどうすればよいですか？

私のユースケースは次のとおりです。

1. ユーザーアクション
2. 最初のジョブを開始します（長さは不明）
3. 最初のジョブが終了するのを待って、2番目のジョブを開始します（既知の長さ）
4. 2番目のジョブが終了するのを待って、3番目のジョブを開始します（既知の長さ）

これを次のようにユーザーに表示したいと思います。

1. グローバルプログレスバーのないメインの[ユーザーアクション]ダイアログがあります（最初のジョブは不明であり、実行の長さによって実際に変動するため、正確な全長を取得できません）
2. このダイアログには、ジョブごとに1つずつ、このジョブごとに1つのプログレスバーがありIProgressMonitor.UNKNOWN、最初のジョブのスタイルでコース外の3つのサブパートがあります。
3. このダイアログでは、進行状況バーが基になるジョブとして順番に更新されます。

これにより、エンドユーザーはそのアクションが3つのサブタスクに分割されていることをすぐに確認でき（サブタスクはエンドユーザーにとって意味があります）、新しいサブタスクが開始されるたびに、このサブタスクの長さを確認できます。 （もちろん最初は不明です）。

多くの検索の後、私はそれを実装できませんでした。今日、これらの3つのサブタスクを3つの個別の連続したダイアログとして報告していますが、エンドユーザーは最初に自分のアクションが最初の不明なサブの終わりに完了すると考える可能性があるという欠点があります。 -タスク。

Quartzはデータベースにジョブを保存できるため、揮発性はありません。しかし、2つのアプリケーション（WebアプリケーションとWebサービス）がある場合、このストアをアプリケーション間で共有するにはどうすればよいですか。

つまり、1つのアプリケーションが通知された他のアプリケーションを実行するジョブを選択した場合、1つのアプリケーションが失敗しても、そのアプリケーションは実行を継続します。

私はHadoopの初心者です。

私の理解によると、Hadoop フレームワークはジョブを FIFO 順 (デフォルトのスケジューリング) で実行します。

特定の時間にジョブを実行するようにフレームワークに指示する方法はありますか?

つまり、そのように毎日午後 3 時にジョブを実行するように設定する方法はありますか?

これに関するご意見は大歓迎です。

ありがとう、R

複数の孤立したテナント間で共有される予定のクラスターでジョブをスケジュールできるジョブ スケジュール システムを構築したいと考えています。

すべてのテナントは、この共有クラスターでのジョブを追跡する必要があります。そのようなものはすでに存在しますか？そのようなスケジューリングシステムの機能を知りたいです。スロットリングからセキュリティまで。どんなリードでも大歓迎です。

次のユースケースに最適な設計を探しています。

ユーザーが終了日時でエンティティを作成するシステムを構築しています。終了時刻に達したらすぐに、これらのエンティティのステータスを期限切れに変更するジョブをスケジュールする必要があります。

これらは私が考えることができる2つの解決策です

• ジョブは毎分実行され、クエリを実行して期限切れのエンティティを確認します (endTime > sysdate)。問題: データベースに負荷がかかります。このクエリを毎分実行すると、データベースに負荷がかかる場合があります。
• エンティティが作成されるとすぐに、各エンティティのジョブをスケジュールします。 問題: システムで作成されるジョブが多すぎます。これらのエンティティが毎日 1000 個作成されます。

上記の2つよりも良い解決策はありますか? 人々は一般的にこれをどのように行うのですか？

さまざまなレポートをさまざまな間隔でさまざまなユーザーに送信する小さなアプリケーションを作成しようとしています。50 または 100 の異なるレポートがさまざまな人に送信されることについて話している可能性があります。毎日、毎週、毎月生成する必要があるレポートがあります。

以前は定期的にタスクを実行するために Quartz ライブラリを使用していました。ただし、物事をシンプルに保つために、単一の Quartz スレッドですべてのレポートを処理するという考えが気に入っています。つまり、スレッドは、たとえば 15 分ごとにすべてのレポートをループし、1 つ以上のレポートを生成して送信する時期かどうかを判断する必要があります。レポートが 12:00 に生成されるか、12:15 に生成されるかは問題ではありません。

どうにかレポートごとに「mon@12:00,wed@12:00」や「fri@09:30」など特定の時間を設定できないかと考えています。次に、それに基づいて、スレッドはレポートを送信する時間であるかどうかを判断します。

私の質問は; 他の誰かがこのようなことをしたことがありますか?このタスクを簡単に実装できるライブラリはありますか?

Gearman のメイン ページでは、ジョブ サーバーが停止した場合にクライアントが新しいジョブ サーバーを取得できるように、複数のジョブ サーバーで実行することについて言及しています。以下のステートメントと図を考えると、ジョブ サーバーが相互に通信していないように見えます。

私たちの質問は、停止したジョブ サーバーでキューに入れられたジョブはどうなるかということです。これらのサーバーの高可用性を確保して、ジョブが障害によって中断されないようにするためのベスト プラクティスは何ですか?

複数のジョブ サーバーを実行し、クライアントとワーカーを、構成されている最初に使用可能なジョブ サーバーに接続させることができます。このようにして、1 つのジョブ サーバーが停止した場合、クライアントとワーカーは自動的に別のジョブ サーバーにフェールオーバーします。あまり多くのジョブ サーバーを実行することは望ましくありませんが、冗長性を確保するために 2 つまたは 3 つのジョブ サーバーを用意することをお勧めします。

ソース

Play フレームワークの優れた点の 1 つは、完全にステートレスであり、リクエスト/レスポンス指向のみであることです。状態 (セッション) のレプリケーションについて心配することなく、アプリをクラウドにデプロイし、ロード バランサーの背後でプレイ インスタンスの数をスケーリングできるため、これは非常に便利です...

しかし最近、HTTP リクエストの外部でいくつかのアプリケーション ロジックを実行する必要があり、Play にはフレームワークによって完全に管理されるジョブを定義できる可能性があることがわかりました。素晴らしいように聞こえますが、疑問が生じます: これらのジョブは、Play で使用されるステートレス モデルにどのように適合するのでしょうか?

1 時間ごとに実行する必要があるメンテナンス タスクがあり、そのためにスケジュールされたジョブを定義するとします。その後、複数の Play インスタンスをロードバランサーの背後にデプロイすると、そのジョブは各インスタンスで同時に開始されますか? もしそうなら、「排他的に」実行する必要があるジョブを処理するための良いアプローチは何でしょうか?

既存の (クラスター化された) インスタンスの JPA モデルを再利用して (したがって、同じデータベースに接続して)、クラスター化されていないサーバーに新しいプレイ インスタンスを作成することを考えていました。この新しいインスタンスにはメンテナンス ジョブのみが含まれ、クラスター化されていないサーバーでホストされているため、ジョブが同時に実行されるリスクはありません。同時に、これにより、既存のクラスター化されたインスタンスを完全にステートレスに保ち、ホスト/負荷分散を容易にすることができます。これは良いアプローチでしょうか？

別の 11g 環境で正常にコンパイルされるパッケージがあります。
DBA ユーザーを使用して XE 10g 環境でコンパイルしようとすると、ORA-00942 エラーが発生します。

テーブルで直接選択を実行しても問題はありません。

エラー テキスト: