Tested with \apache-jmeter-r1804400\ and it works
Thanks

> -----Original Message-----
> From: Philippe Mouawad [mailto:p.moua...@ubik-ingenierie.com]
> Sent: Tuesday, 8 August 2017 3:41 PM
> To: dev@jmeter.apache.org
> Subject: Re: Shutdown test releases thundering herd
> 
> Hello,
> I pushed yesterday a fix to the bugzilla you opened.
> Can you test nightly build and give feedback to confirm issue is fixed ?
> 
> Thanks
> 
> On Friday, August 4, 2017, Antony Bowesman <
> antony.bowes...@williamhill.com.au> wrote:
> 
> > My temporary solution was to use a static volatile variable in my Java
> > sampler and make my samplers implement Interruptible, which will then
> > get called if a sampler happens to be active. As our tests are pretty
> > heavy, there will almost always be a sampler running, so all samplers
> > test that state in runTest() and ignore if set.
> >
> >
> > > -----Original Message-----
> > > From: Andrey Pokhilko [mailto:a...@ya.ru <javascript:;>]
> > > Sent: Wednesday, 2 August 2017 6:48 PM
> > > To: dev@jmeter.apache.org <javascript:;>
> > > Subject: Re: Shutdown test releases thundering herd
> > >
> > > I agree this is an issue. I have faced this long time ago with
> > > question
> > of timers
> > > in JMeter, there's no way to make thread to not produce sample if it
> > waits on
> > > timer. Let's fix it finally.
> > >
> > > Antony, did you find existing bugzilla for this issue? If there's
> > > none,
> > please
> > > file one and we'll work on fixing it.
> > >
> > > Andrey Pokhilko
> > >
> > > On 08/02/2017 11:34 AM, sebb wrote:
> > > > On 2 August 2017 at 03:42, Antony Bowesman
> > > > <antony.bowes...@williamhill.com.au <javascript:;>> wrote:
> > > >> Seems like there's a flaw in the shutdown logic
> > > >>
> > > >> When a test is running, it goes through JMeterThread.
> > > executeSamplePackage() where it goes into the
> > > delay(pack.getTimers())
> > call.
> > > >>
> > > >> If you shut down a test, it will interrupt the timers and you
> > > >> will see these messages in jmeter.log
> > > >>
> > > >> jmeter.threads.JMeterThread: The delay timer was interrupted -
> > > >> probably did not wait as long as intended
> > > >>
> > > >> As a result, all threads blocked waiting to sample() will get
> > released at
> > > pretty much the same time and as the JMeter iteration logic does the
> > delay
> > > _before_ the sample() rather than after, it means all threads will
> > > go
> > into
> > > sample() at about the same time.
> > > > If the test is stopping it does not make sense to start a new sample.
> > > > That seems like a bug, but I'm surprised it has not been noticed
> > previously.
> > > >
> > > >> We've had cases where we've had to stop a production test as
> > > >> we're
> > > breaking it and the shutdown exacerbates the problem.
> > > >>
> > > >> As the JMeterThread.stop() sets the running flag to false, it's
> > > >> probably a simple fix to wrap the code following the delay() call
> > > >> with if (running) {
> > > >>
> > > >> }
> > > >>
> > > >> With some possible additional logic for the compiler.done() call,
> > which I
> > > don't yet understand.
> > > >>
> > > >> Another option would be to expose the running flag via
> > > JMeterThread.isRunning() so that the sampler can find out if it's
> > running, but
> > > that sounds more like a hack to solve the problem.
> > > >>
> > > >> Is this a bug or a feature?
> > > >>
> > > >> Antony
> > > >>
> >
> >
> 
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
> 
> UBIK LOAD PACK Web Site
> <https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.ubikloadpack.com%2F&data=02%7C01%7CAntony.Bowesman%40williamhi
> ll.com.au%7C21820516a491468a236408d4de202273%7Cee4fd668f99f4f05a74b
> 6405db44621a%7C0%7C0%7C636377676980930092&sdata=rbKj3Xi0D4XHjMnZ
> TXNVNKb9HkZv4moOLT3epRADk8c%3D&reserved=0>
> 
> UBIK LOAD PACK on TWITTER
> <https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwi
> tter.com%2Fubikloadpack&data=02%7C01%7CAntony.Bowesman%40william
> hill.com.au%7C21820516a491468a236408d4de202273%7Cee4fd668f99f4f05a7
> 4b6405db44621a%7C0%7C0%7C636377676980930092&sdata=r9YgmJ8hNV%2
> FNlQGds9Bt3r54p9ypp5uKcHlkqpmwXUg%3D&reserved=0>

Reply via email to