Job moved from inflight queue to comma-joined queue on worker shutdown in RESET_TO_HIGHEST_PRIORITY strategy.
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- java, redis
調査の方向性
WorkerPoolImpl::getNextQueue() と WorkerPoolImpl::removeInFlight() から始め、次に fromMultiplePriorityQueues.sha を調べて、ポーリングに使用されるキューと、shutdown 時の requeueing に使用されるキューを比較します。q1、q2、q3、q4 を使って RESET_TO_HIGHEST_PRIORITY シナリオを再現し、shutdown によって namespace:queue:q1,q2,q3,q4 のようなポーリングされない Redis キーにジョブが残らないことを確認します。
索引モデルが issue の本文から書いたものです。
説明
I have noticed that in certain scenarios (immediate worker shutdown), jobs are removed from the inflight queue and then moved to another queue.
Consider the case where I have the following queues: q1, q2, q3, q4.
My workers are meant to process jobs from these queues.
WorkerPoolImpl::getNextQueue() returns a string of "q1,q2,q3,q4" (for RESET_TO_HIGHEST_PRIORITY) and this is stored in curQueue variable.
During pop, the lua script (fromMultiplePriorityQueues.sha) pops from a single queue and returns the job. But when the worker is shutting down, the jobs are removed from the inflight queue and pushed to a queue "q1,q2,q3,q4". resulting in a new key on redis "namespace:queue:q1,q2,q3,q4". This code is in WorkerPoolImpl::removeInFlight.
What is the purpose of storing the jobs in this comma-joined queue? From what I could see, no worker would poll from this queue as the lua script would always pop from the individual queues.
- 主要言語
- Java
- スター
- 629
- フォーク
- 132
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
gresrun/jesque のほかの issue
-
Pooled clients leak a connection per call: pipelines and transactions taken from UnifiedJedis are never closed対応中かも @ali-jawad が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
-
Latest jedis SDK support?再び着手できるかも @gresrun が 295 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンDiscussion
-
難易度 3/5 1〜2日 初心者へのやさしさ 38/100
-
Redis Cluster Issueオープン
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
似ている issue
-
[Bug]: REST API URL starting with "http" but no scheme (e.g. httpbin.org/get) is not given an http:// prefix対応中かも @ItsDeadlyProgrammer が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
appsmithorg/appsmith#42471 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
code-maintenance
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
bug priority: medium Review effort [1-5]: 3 status: needs-triage type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
carlos-emr/carlos#5258 ·
メンテナーはふだん 1 日以内に返信
-
bug: author create/update with an unknown avatarId returns 404 instead of 400 UNKNOWN_REFERENCE対応中かも @Vinu2111 が今日担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
atomityhq/blog-cms#59 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信