On 14 July 2012 14:19, Philippe Mouawad <[email protected]> wrote: > Hello Sebb, > I am not sure we shoud use the approach of Http Sampler. > Because for example a future enhancement I see to OnDemandThreadGroup is to > add Thread Pooling, and in this case user will input the min/max size of > the pool. > In this case the HttpSampler approach won't fit unless user inputs > configuration in jmeter.properties.
Why not? Surely we can just add the extra fields to the GUI? Or perhaps I'm missing something. > I don't see why introducing a new Test Element is a problem. More to document; more documentation for users to read. At present, the thread groups GUIs are identical apart from the name. Much easier to support this via an additional checkbox. > And why would users want to convert thread group to new one ? Because they would like to use the new feature with existing tests. > Another point I have in mind is existing plugins that extend > AbstractThreadGroup, are you sure we won't break them with this approach ? That's a separate issue. > In my understanding, this Test Element answers a new kind of Test case if It's not so different that it requires a new GUI, unlike the setUp and tearDown thread groups. > you remember what Kirk Pepperdine was saying in initial conversation:* > "However, I'm often simulating open systems which means I do not want rate > of entry into the system to be controlled by the performance of the system > (rate of exit). "* > So I find it Ok to create a new Test Element, but as it's how I build it, > it's regular I agree with myself :-) > > But if you want to change things, go ahead as I am not sure to understand > how you want to change it. I don't know yet how I would change it. I'll let the list know later. > Regards > Philippe > > On Sat, Jul 14, 2012 at 12:57 PM, sebb <[email protected]> wrote: > >> On 14 July 2012 09:18, Philippe Mouawad <[email protected]> >> wrote: >> > Hello Sebb , >> > I saw 3 reasons which Led me to implementing it this way: >> > - looking at use case of this feature it seems to me it's different from >> > current thread group and you might want to mix the 2 behaviours in one >> test >> > plan. For me typical usage of on demand Will be to put lot of threads and >> > very few iterations , maybe only one >> >> As far as I can tell, that does not require a separate test element. >> >> > - code of thread group would have been too complex >> > - currently thread group is not Much impacted and we can improve on >> demand >> > Without risks on existing plans. >> >> It may well have made updates somewhat simpler; depends on how the >> combined thread group was implemented. >> >> But is it worth the inconvenience to end users? >> It's currently not at all easy to convert between the two styles of >> thread group. >> >> I think we need to look again at how the code could be rearranged; it >> might be possible to have the best of both worlds. >> Possibly using something like the approach used for the HTTP Sampler. >> If we can keep the same test plan classes, we can add new >> implementation classes if necessary without breaking test plans. >> >> > Regards >> > Philippe >> > >> > >> > On Saturday, July 14, 2012, sebb wrote: >> > >> >> I think it's good that the functionality of the onDemand thread group >> >> now exists. >> >> >> >> I just wonder why it was not done as an option on the existing thread >> >> group? >> >> >> >> Seems to me that would be simpler - and also easier to convert >> >> existing test plans if required (or indeed convert back). >> >> >> >> Is there a reason why the functionality has to be done as a separate >> >> class, or could the code be incorporated into the existing thread >> >> group? >> >> >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > > -- > Cordialement. > Philippe Mouawad.
