You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Thad Smith <th...@yahoo.com> on 2003/05/05 06:29:29 UTC
Calling all thread gurus
Developers,
I've recently written a throughput controller that
allows you to specify either how many times a block of
code should be executed or how often (represented as a
percentage) a block of code should be executed. The
problem I'm having with it is the option to make it do
it's calculation over each thread instead of just the
single thread...Basically it allows you to say run
this block of code exactly 8,245 times no matter how
many threads you're running. Works great in theory,
and even great in the debugger...just not in real life
yet. If you know quite a bit about synchronizing
threads (and I thought I did) please check out the
code and let me know if you find any problems in it.
The class is
org.apache.jmeter.control.ThroughputController. I've
been working on it all weekend and am about to pull my
hair clean out of my skull trying to figure out what
is happening!
Here's a quick explanation of how the code works:
because I'm trying to synchronize between an object
and its cloans (and not each instance of the class),
an object will share two locks with its cloans:
iterationLock and numExecutionsLock. The values that
I'm trying to share between the object and it's cloans
are how many times I've been asked to be executed
(iteration) and the actual number of times that I have
executed (numExecutions) kept as Integers since
multiple objects can't keep a reference to an int.
Because Integers are immutable and this value will be
changing I wrote an IntegerWrapper class that allows
the objects to share access to an updatable object
which will hold the actual Integer.
As I said, when I step through the code in a debugger
it works great (which makes it extremely frustrating),
but outside of that you might as well ignore that the
per user option is available to be disabled.
Thanks for any help I might find.
Regards,
Thad
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Calling all thread gurus
Posted by Thad Smith <th...@yahoo.com>.
That did it.
Thanks,
Thad
--- mstover1@apache.org wrote:
> Thad,
> I looked at this for a while this morning, and
> the problem doesn't seem to
> be in your synchronization techniques but instead in
> the initialize() method.
> When initialize() is called, you are setting the
> number of executions to zero.
> But, since threads don't all start at the same time,
> this means sometimes
> thread #1 has done an execution, and incremented
> it's execution count to 1,
> but then thread #2 starts, and initializes the
> execution count back to 0. Thus,
> all your extra executions are coming from the start
> of the test because the
> count is getting repeatedly initialized.
>
> What you need to do is make sure that the count is
> only initialized once, even
> though initialize is called for every thread. To do
> this, you may want to either
> implement TestListener to initialize these values,
> or override
> setRunningVersion for TestElement.
>
> -Mike
>
> On 4 May 2003 at 21:29, Thad Smith wrote:
>
> > Developers,
> >
> > I've recently written a throughput controller that
> > allows you to specify either how many times a
> block of
> > code should be executed or how often (represented
> as a
> > percentage) a block of code should be executed.
> The
> > problem I'm having with it is the option to make
> it do
> > it's calculation over each thread instead of just
> the
> > single thread...Basically it allows you to say run
> > this block of code exactly 8,245 times no matter
> how
> > many threads you're running. Works great in
> theory,
> > and even great in the debugger...just not in real
> life
> > yet. If you know quite a bit about synchronizing
> > threads (and I thought I did) please check out the
> > code and let me know if you find any problems in
> it.
> > The class is
> > org.apache.jmeter.control.ThroughputController.
> I've
> > been working on it all weekend and am about to
> pull my
> > hair clean out of my skull trying to figure out
> what
> > is happening!
> >
> > Here's a quick explanation of how the code works:
> > because I'm trying to synchronize between an
> object
> > and its cloans (and not each instance of the
> class),
> > an object will share two locks with its cloans:
> > iterationLock and numExecutionsLock. The values
> that
> > I'm trying to share between the object and it's
> cloans
> > are how many times I've been asked to be executed
> > (iteration) and the actual number of times that I
> have
> > executed (numExecutions) kept as Integers since
> > multiple objects can't keep a reference to an int.
> > Because Integers are immutable and this value will
> be
> > changing I wrote an IntegerWrapper class that
> allows
> > the objects to share access to an updatable object
> > which will hold the actual Integer.
> >
> > As I said, when I step through the code in a
> debugger
> > it works great (which makes it extremely
> frustrating),
> > but outside of that you might as well ignore that
> the
> > per user option is available to be disabled.
> >
> > Thanks for any help I might find.
> >
> > Regards,
> >
> > Thad
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Search - Faster. Easier. Bingo.
> > http://search.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-dev-help@jakarta.apache.org
> >
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Calling all thread gurus
Posted by ms...@apache.org.
Thad,
I looked at this for a while this morning, and the problem doesn't seem to
be in your synchronization techniques but instead in the initialize() method.
When initialize() is called, you are setting the number of executions to zero.
But, since threads don't all start at the same time, this means sometimes
thread #1 has done an execution, and incremented it's execution count to 1,
but then thread #2 starts, and initializes the execution count back to 0. Thus,
all your extra executions are coming from the start of the test because the
count is getting repeatedly initialized.
What you need to do is make sure that the count is only initialized once, even
though initialize is called for every thread. To do this, you may want to either
implement TestListener to initialize these values, or override
setRunningVersion for TestElement.
-Mike
On 4 May 2003 at 21:29, Thad Smith wrote:
> Developers,
>
> I've recently written a throughput controller that
> allows you to specify either how many times a block of
> code should be executed or how often (represented as a
> percentage) a block of code should be executed. The
> problem I'm having with it is the option to make it do
> it's calculation over each thread instead of just the
> single thread...Basically it allows you to say run
> this block of code exactly 8,245 times no matter how
> many threads you're running. Works great in theory,
> and even great in the debugger...just not in real life
> yet. If you know quite a bit about synchronizing
> threads (and I thought I did) please check out the
> code and let me know if you find any problems in it.
> The class is
> org.apache.jmeter.control.ThroughputController. I've
> been working on it all weekend and am about to pull my
> hair clean out of my skull trying to figure out what
> is happening!
>
> Here's a quick explanation of how the code works:
> because I'm trying to synchronize between an object
> and its cloans (and not each instance of the class),
> an object will share two locks with its cloans:
> iterationLock and numExecutionsLock. The values that
> I'm trying to share between the object and it's cloans
> are how many times I've been asked to be executed
> (iteration) and the actual number of times that I have
> executed (numExecutions) kept as Integers since
> multiple objects can't keep a reference to an int.
> Because Integers are immutable and this value will be
> changing I wrote an IntegerWrapper class that allows
> the objects to share access to an updatable object
> which will hold the actual Integer.
>
> As I said, when I step through the code in a debugger
> it works great (which makes it extremely frustrating),
> but outside of that you might as well ignore that the
> per user option is available to be disabled.
>
> Thanks for any help I might find.
>
> Regards,
>
> Thad
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org