On Mon, Mar 30, 2020 at 1:34 PM Vladimir Sitnikov < [email protected]> wrote:
> >Custom scripts can also modify props (I guess you have this in mind, but > >just not to skip it) > > That is true. I expect that all calls to "public JMeterProperty > getProperty(String key)" should be treated as unsafe. > What do you mean by unsafe ? > > Frankly speaking, it would probably be great if we could split > configuration and execution phases. > Currently, JMeter uses the same object (e.g. AbstractSampler) to configure > the behavior in the test plan, and the very same object is used for the > execution. > > However, the goals there are completely different: > 1) Configuration needs backward compatibility (e.g. load old test plans), > configuration needs various setters, generic visitor for "search substring" > features, and so on > 2) Execution needs much less. It does not need UI, it needs no backward > compatibility. It just needs enough information to execute stuff. > > It would be much better if we > removed org.apache.jmeter.testelement.AbstractTestElement#setRunningVersion > and replaced it with something like > `AbstractTestElement#getExecutorNode()` > > > Then we would be able to build the executable test plan just once and skip > cloning the test plan nodes altogether. > Unfortunately, it is not clear how much effort would it take to rewrite the > existing samplers and the controllers to the new approach :( > > So the plan could probably be like: > JMeter 5.3 or 5.4: > rewrite org.apache.jmeter.testelement.AbstractTestElement#propMap to use > Dexx HashMap; add coroutine-based executor. That would unlock testing with > high number of threads. > For me this should be 6.0 (even if it's backward compatible), it's a major change that needs to be highlighted. JMeter 6.0: split AbstractTestElement into "configuration" and "execution" > classes > > Vladimir > -- Cordialement. Philippe Mouawad.
