TCPSampler TristateCheckBox implementation

[sebb <se...@gmail.com>]

I've committed an initial implementation of TCP Sampler with tristates
for close connection and no delay. Reuse connection still uses an
ordinary checkbox for comparison.

Note that noDelay was originally implemented to save both false and
true values; i.e. the boolProp would always be present.
This means the GUI will never display the indeterminate value when
reading existing test plans.

However, the new close connection setting was implemented to omit the
default value when saving to the JMX, so existing plans will show the
default (false) as indeterminate.
Also, the GUI will never show the default value for close connection -
it will always show indeterminate.

The effect is the same, but is quite confusing.
We could allow the GUI to show the default by ensuring that default
values are written to the JMX file (as with noDelay), but existing
test plans would still appear to change the setting.

So I think we need another solution, e.g. could we save indeterminate
values as some other JMX entry?
This would require changing how the properties are merged so that
indeterminate values are ignored.

This might also play better with TestBeans so I will have a look a bit later.

Meanwhile please have a look at how the TCP Sampler and TCP Config
elements look and behave and see if there are any other items that
could be improved.

Thanks!

Re: TCPSampler TristateCheckBox implementation

[sebb <se...@gmail.com>]

On 8 December 2012 14:30, sebb <se...@gmail.com> wrote:
> I've committed an initial implementation of TCP Sampler with tristates
> for close connection and no delay. Reuse connection still uses an
> ordinary checkbox for comparison.
>
> Note that noDelay was originally implemented to save both false and
> true values; i.e. the boolProp would always be present.
> This means the GUI will never display the indeterminate value when
> reading existing test plans.
>
> However, the new close connection setting was implemented to omit the
> default value when saving to the JMX, so existing plans will show the
> default (false) as indeterminate.
> Also, the GUI will never show the default value for close connection -
> it will always show indeterminate.
>
> The effect is the same, but is quite confusing.
> We could allow the GUI to show the default by ensuring that default
> values are written to the JMX file (as with noDelay), but existing
> test plans would still appear to change the setting.
>
> So I think we need another solution, e.g. could we save indeterminate
> values as some other JMX entry?
> This would require changing how the properties are merged so that
> indeterminate values are ignored.
>
> This might also play better with TestBeans so I will have a look a bit later.

I was forgetting that the current implementation is broken, regardless
of whether the default boolean value is saved or not.

1) If the default value is saved, i.e. the JMX always contains an
entry for the property, then the sampler value will always win,
because it will overwrite any config value. The config value is
useless.

2) If the default value is not saved, then the config element setting
will be used if it is not the default, i.e. the sampler can only
override a missing (default) config entry. This is because the sampler
entry will also be omitted if it is the default.

For case 1) adding the indeterminate value allows the test element to
omit the property.
This works well, as per the noDelay example. There is a 1-1
correspondance between JMX and display and behaviour.

For case 2) the problem is that it's not possible to set the default
value on the GUI.
The problem here is that there are two possible meanings for a missing
property - indeterminate or default.
If we insist that default values are written to the file, then the GUI
can retain all three values.
However, the user will initially see the indeterminate value instead
of the true/false default.
As mentioned before, that reflects how the test plan behaves; it is
only a visual difference.
If the user re-saves the test plan without changing the indeterminate
values, it will remain unchanged.

So I now think it's just a question of documentation.

I've changed the TCP Sampler close connection to always save the
default value; the GUI now behaves better.

> Meanwhile please have a look at how the TCP Sampler and TCP Config
> elements look and behave and see if there are any other items that
> could be improved.
>
> Thanks!