Change JMeter properties backend to a lock-free representation to avoid run-time lock contention
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- java
- 領域
- performance, tooling
調査の方向性
まず、JSR223 Groovy スクリプトと ${__P()}/${__property()} 関数で使用される JMeter のプロパティバックエンドを追跡します。暗黙の props オブジェクトを介した並行読み取りでグローバルロックの競合を回避しつつ、書き込みは同期された状態で java.util.Properties と互換性を保てる方法を定義します。並行アクセス時にも既存の型の動作が維持されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Use case
Description
In high-concurrency performance testing scenarios, global property queries performed during active test execution (for example, through JSR223 Groovy scripts accessing the implicit props object or through ${__P()} / ${__property()} functions) create a global synchronization bottleneck.
java.util.Properties inherits directly from java.util.Hashtable, where core accessors like .get(Object) and mutators like .put() are declared as synchronized methods. In highly concurrent test plans (e.g. 500+ threads executing JSR223 elements concurrently), threads end up serialization-blocked waiting to acquire the monitor lock of the global properties instance.
Possible solution
Introduce a subclass of java.util.Properties named ConcurrentProperties which internally delegates read queries to a backing ConcurrentHashMap, while keeping writes synchronized and in sync with the parent Hashtable data model. This provides completely lock-free read lookups under concurrent scripts while maintaining full type compatibility (instanceof java.util.Properties).
Possible workarounds
No response
JMeter Version
6.0.0-SNAPSHOT
Java Version
No response
OS Version
No response
- 主要言語
- Java
- スター
- 9.6k
- フォーク
- 2.3k
- 平均マージ
- 20時間 42分
- マージ済み PR（30日）
- 10
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/jmeter のほかの issue
-
[Bug] Typo in assertion property name: "Asserion.test_strings" missing 't'対応中かも @waterWang が 60 日前に担当しました。 オープンdefect to-triage
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
apache/jmeter#6751 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement to-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
RandomDate ignores inclusive end date and throws when start == end対応中かも @weillercarvalho が 336 日前に担当しました。 オープンdefect to-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
apache/jmeter#6609 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
-
documentation to-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
invalid wontfix
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
apache/jmeter#5770 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
account bug communication lecture
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
-
area/server bug P2
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/java-sdk#1196 ·
メンテナーはふだん 1 日以内に返信