You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Antony Bowesman <An...@williamhill.com.au> on 2017/08/02 02:42:32 UTC
Shutdown test releases thundering herd
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.
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
Re: Shutdown test releases thundering herd
Posted by Andrey Pokhilko <ap...@ya.ru>.
Thanks, we'll take a look on fixing this.
Andrey Pokhilko
On 08/04/2017 02:37 AM, Antony Bowesman wrote:
> Hi Andrey,
>
> Couldn't find an existing bug, so I raised
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
>
> Thanks
> Antony
>
>
>> -----Original Message-----
>> From: Andrey Pokhilko [mailto:apc4@ya.ru]
>> Sent: Wednesday, 2 August 2017 6:48 PM
>> To: dev@jmeter.apache.org
>> 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
>>> <An...@williamhill.com.au> 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
>>>>
RE: Shutdown test releases thundering herd
Posted by Antony Bowesman <An...@williamhill.com.au>.
Hi Andrey,
Couldn't find an existing bug, so I raised
https://bz.apache.org/bugzilla/show_bug.cgi?id=61380
Thanks
Antony
> -----Original Message-----
> From: Andrey Pokhilko [mailto:apc4@ya.ru]
> Sent: Wednesday, 2 August 2017 6:48 PM
> To: dev@jmeter.apache.org
> 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
> > <An...@williamhill.com.au> 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
> >>
RE: Shutdown test releases thundering herd
Posted by Antony Bowesman <An...@williamhill.com.au>.
Tested with \apache-jmeter-r1804400\ and it works
Thanks
> -----Original Message-----
> From: Philippe Mouawad [mailto:p.mouawad@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.Bowesman@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:apc4@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.Bowesman@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>
Re: Shutdown test releases thundering herd
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
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.Bowesman@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:apc4@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.Bowesman@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 <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
RE: Shutdown test releases thundering herd
Posted by Antony Bowesman <An...@williamhill.com.au>.
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:apc4@ya.ru]
> Sent: Wednesday, 2 August 2017 6:48 PM
> To: dev@jmeter.apache.org
> 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
> > <An...@williamhill.com.au> 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
> >>
Re: Shutdown test releases thundering herd
Posted by Andrey Pokhilko <ap...@ya.ru>.
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
> <An...@williamhill.com.au> 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
>>
Re: Shutdown test releases thundering herd
Posted by sebb <se...@gmail.com>.
On 2 August 2017 at 03:42, Antony Bowesman
<An...@williamhill.com.au> 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
>