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.
I don't see why introducing a new Test Element is a problem. And why would users want to convert thread group to new one ? Another point I have in mind is existing plugins that extend AbstractThreadGroup, are you sure we won't break them with this approach ? In my understanding, this Test Element answers a new kind of Test case if 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. 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.
