apache / apache/jmeter

TestStateListener implementation should be supported for NoThreadClone elements only

Open
#5,709 0 comments 0 reactions 0 assignees View on GitHub
os: All P2
Dominant language
Java
Stars
9.5k
Forks
2.3k
Avg merge
1d 22h
Merged PRs (30d)
5

Description

@vlsi ([Bug 66270](https://bz.apache.org/bugzilla//show_bug.cgi?id=66270&redirect=false)):
Currently, JMeter notifies TestStateListener from a single thread only, and it collects listeners **before** they are cloned for the execution.

For instance, HTTPSamplerBase is cloned for every thread (because it has execution state fields), so it looks strange to implement TestStateListener. What was the expected outcome? Did HTTPSamplerBase authors expect that JMeter would execute "testEnded" on each cloned HTTPSamplerBase instance? Did HTTPSamplerBase authors expect that "testEnded" would be called for "non-cloned" instance only? Frankly speaking, both options sound strange to me, and I think HTTPSamplerBase should not really implement TestStateListener.

That creates two issues:
1) StandardJMeterEngine keeps the collection (see SearchByClass<>(TestStateListener.class)) of all TestStateListener implementations for the duration of the test.

2) HTTPSamplerBase is cloned into the execution threads, so it is unclear what would be outcome of calling the notifications (testStarted, testEnded) on an element that is not associated with a thread.

I'm inclined we should deprecate TestStateListener for objects cloned into individual execution threads. In other words, it looks like TestStateListeners should be executed for "global-like" services only.

Of course, we could try calling "testStarted" within each execution thread, however, I am not sure what would be the use case for it, and it was not implemented previously.

Severity: normal
OS: All

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.