Re: OnDemand thread group

2012-07-14 Thread sebb
On 14 July 2012 19:52, Philippe Mouawad wrote: > Ok , I agree on what you say on alternate implementation. > > But Regarding what you said previously: > "The current fix does not actually address that issue." > > I don't understand ? Why and if not which issue is not addressed ? > Can you in this

Re: OnDemand thread group

2012-07-14 Thread Philippe Mouawad
Ok , I agree on what you say on alternate implementation. But Regarding what you said previously: "The current fix does not actually address that issue." I don't understand ? Why and if not which issue is not addressed ? Can you in this case clarify what Kirk Pepperdine meant ? Thanks Regards Ph

Jenkins build is back to normal : JMeter-trunk #2371

2012-07-14 Thread Apache Jenkins Server
See

Re: OnDemand thread group

2012-07-14 Thread sebb
On 14 July 2012 17:04, Philippe Mouawad wrote: > Hello, > I understand it differently, what this feature does is that it enables > creation of thousands of short lived threads while doing so with current > implementation didn't enable this. Yes, that is also true. I should have mentioned that. H

Re: OnDemand thread group

2012-07-14 Thread Philippe Mouawad
Hello, I understand it differently, what this feature does is that it enables creation of thousands of short lived threads while doing so with current implementation didn't enable this. With Thread Group, to create 1 threads that run 1 HTTP requests , will make JMeter create 1 threads at T

buildbot success in ASF Buildbot on jmeter-trunk

2012-07-14 Thread buildbot
The Buildbot has detected a restored build on builder jmeter-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/jmeter-trunk/builds/869 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: scheduler Build Source

Re: OnDemand thread group

2012-07-14 Thread sebb
On 14 July 2012 15:39, sebb wrote: > On 14 July 2012 14:19, Philippe Mouawad 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

Build failed in Jenkins: JMeter-trunk #2370

2012-07-14 Thread Apache Jenkins Server
See Changes: [pmouawad] Bug 53522 - Cache Manager should not store at all response with header "no-cache" and store other types of Cache-Control having max-age value Added test case Added sleep to ensure entries become invalid after their

buildbot failure in ASF Buildbot on jmeter-trunk

2012-07-14 Thread buildbot
The Buildbot has detected a new failure on builder jmeter-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/jmeter-trunk/builds/868 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: scheduler Build Source St

Re: OnDemand thread group

2012-07-14 Thread sebb
On 14 July 2012 14:19, Philippe Mouawad 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 cas

Re: OnDemand thread group

2012-07-14 Thread Philippe Mouawad
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 conf

Re: OnDemand thread group

2012-07-14 Thread sebb
On 14 July 2012 09:18, Philippe Mouawad 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

Re: OnDemand thread group

2012-07-14 Thread Philippe Mouawad
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