Re: Scheduler problems
Yes, past experience (e.g. with the HTTP Sampler) shows that it's
generally better to have more funcionality in a single element type
rather than many similar elements to choose from. I'd say this holds as
far as the GUI doesn't get too cluttered.
+1 on enhancing ThreadGroup
--
Salut,
Jordi.
Dave Brewster wrote:
+1 on enhancing ThreadGroup.
Btw... do most of you read both groups? Should I post things like this to the dev board or does it not matter?
Thanks,
Dave
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 5:49 AM
To: JMeter Users List
Subject: RE: Scheduler problems
I'd be in favor of just changing the code. I don't think anyone would
depend on the current behavior.
I also think the current ThreadGroup should just be enhanced,
rather than subclassed.
-Mike
On 23 Oct 2003 at 13:29, BAZLEY, Sebastian wrote:
-Original Message-
From: Dave Brewster [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 01:56
To: [EMAIL PROTECTED]
Subject: Scheduler problems
I'm trying to develop my own listener that acts like a
duration scheduled thread group. I.e. the thread group runs
for X number of seconds.
See below - I think it would be best to enhance ThreadGroup
instead.
But if you want to stop a thread, or a test directly from a sampler
or a
listener, there are two new methods in Sampler -
setThreadStop(boolean) and
setTestStop(boolean). These set variables which are picked up
by
ThreadGroup.
All of this was easy to do with on exceptions. I'm running
into problems with the startScheduler method in JMeterThread.
Threads "randomly" die before they start due to the code in
this method the code is:
public void startScheduler()
{
long delay = (startTime - System.currentTimeMillis());
if (delay > 0)
{
try
{
running = true;
Thread.sleep(delay);
}
catch (Exception e)
{
}
}
else
{
running = false;
}
}
IMHO it should be changed to:
public void startScheduler()
{
running = true;
long delay = (startTime - System.currentTimeMillis());
if (delay > 0)
{
try
{
Thread.sleep(delay);
}
catch (Exception e)
{
}
}
}
In most (if not all?) cases one doesn't care if the start
time is in the past; the thread should still start.
Thoughts? Is it possible to get this into the main line if
things seem fine? (I've noticed other posted around this
same issue as well).
I agree - if the start time has passed, why not start anyway?
I'll see if I can get that into CVS in a day or so,
Just in case anyone still wants the old behaviour, I'll make it
dependent on
a JMeter property, which defaults to the new behaviour. [e.g.
synchronize.start_anyway=true]
The two methods I'm overriding in this class are (and it
extends from ThreadGroup):
private long _startTime = 0;
public long getStartTime() {
_startTime = System.currentTimeMillis();
return _startTime;
}
/**
* Ends after specified duration
* @return
*/
public long getEndTime() {
long baseValue =
getProperty(TEST_DURATION).getLongValue();
String overrideStr =
System.getProperty(TEST_DURATION_PROP, null);
if (overrideStr == null)
{
overrideStr =
JMeterUtils.getPropDefault(TEST_DURATION_PROP, null);
}
try {
if (overrideStr != null)
{
baseValue = Long.parseLong(overrideStr);
}
} catch (NumberFormatException ex)
{
throw new RuntimeException("Could not convert number to
int " + overrideStr);
}
return _startTime + (baseValue * 1000L);
}
Thanks,
Rather than creating a new class, I think it would be better to
enhance the
existing ThreadGroup, and add a new field for the duration of the
test.
Or perhaps one could allow the start time to be empty, in which
case the the
end time would be treated as a duration.
Comments?
S.
-
To unsubscribe, e-mail: jmeter-user-
[EMAIL PROTECTED]
For additional commands, e-mail: jmeter-user-
[EMAIL PROTECTED]
--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scheduler problems - where to post
Depend on what you mean by "you", I guess! I imagine all the JMeter committers read both groups. [I do, and so does Mike] == In my view, discussions on enhancing JMeter would probably be best in jmeter-dev - a summary can always be copied to jmeter-user when the discussion has been resolved, or if wider input is needed. S. -Original Message- From: Dave Brewster [mailto:[EMAIL PROTECTED] Sent: 23 October 2003 17:19 To: JMeter Users List Subject: RE: Scheduler problems +1 on enhancing ThreadGroup. Btw... do most of you read both groups? Should I post things like this to the dev board or does it not matter? Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 5:49 AM To: JMeter Users List Subject: RE: Scheduler problems I'd be in favor of just changing the code. I don't think anyone would depend on the current behavior. I also think the current ThreadGroup should just be enhanced, rather than subclassed. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scheduler problems
+1 on enhancing ThreadGroup.
Btw... do most of you read both groups? Should I post things like this to the dev
board or does it not matter?
Thanks,
Dave
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 5:49 AM
To: JMeter Users List
Subject:RE: Scheduler problems
I'd be in favor of just changing the code. I don't think anyone would
depend on the current behavior.
I also think the current ThreadGroup should just be enhanced,
rather than subclassed.
-Mike
On 23 Oct 2003 at 13:29, BAZLEY, Sebastian wrote:
> > -Original Message-
> > From: Dave Brewster [mailto:[EMAIL PROTECTED]
> > Sent: 23 October 2003 01:56
> > To: [EMAIL PROTECTED]
> > Subject: Scheduler problems
> >
> >
> > I'm trying to develop my own listener that acts like a
> > duration scheduled thread group. I.e. the thread group runs
> > for X number of seconds.
> >
> See below - I think it would be best to enhance ThreadGroup
instead.
>
> But if you want to stop a thread, or a test directly from a sampler
or a
> listener, there are two new methods in Sampler -
setThreadStop(boolean) and
> setTestStop(boolean). These set variables which are picked up
by
> ThreadGroup.
>
> > All of this was easy to do with on exceptions. I'm running
> > into problems with the startScheduler method in JMeterThread.
> > Threads "randomly" die before they start due to the code in
> > this method the code is:
> >
> > public void startScheduler()
> > {
> > long delay = (startTime - System.currentTimeMillis());
> > if (delay > 0)
> > {
> > try
> > {
> > running = true;
> > Thread.sleep(delay);
> > }
> > catch (Exception e)
> > {
> > }
> > }
> > else
> > {
> > running = false;
> > }
> > }
> >
> > IMHO it should be changed to:
> >
> > public void startScheduler()
> > {
> > running = true;
> > long delay = (startTime - System.currentTimeMillis());
> > if (delay > 0)
> > {
> > try
> > {
> > Thread.sleep(delay);
> > }
> > catch (Exception e)
> > {
> > }
> > }
> > }
> >
> > In most (if not all?) cases one doesn't care if the start
> > time is in the past; the thread should still start.
> >
> > Thoughts? Is it possible to get this into the main line if
> > things seem fine? (I've noticed other posted around this
> > same issue as well).
> >
>
> I agree - if the start time has passed, why not start anyway?
>
> I'll see if I can get that into CVS in a day or so,
>
> Just in case anyone still wants the old behaviour, I'll make it
dependent on
> a JMeter property, which defaults to the new behaviour. [e.g.
> synchronize.start_anyway=true]
>
> >
> > The two methods I'm overriding in this class are (and it
> > extends from ThreadGroup):
> >
> > private long _startTime = 0;
> >
> > public long getStartTime() {
> > _startTime = System.currentTimeMillis();
> > return _startTime;
> > }
> >
> > /**
> >* Ends after specified duration
> >* @return
> >*/
> > public long getEndTime() {
> > long baseValue =
getProperty(TEST_DURATION).getLongValue();
> > String overrideStr =
System.getProperty(TEST_DURATION_PROP, null);
> > if (overrideStr == null)
> > {
> > overrideStr =
> > JMeterUtils.getPropDefault(TEST_DURATION_PROP, null);
> > }
> > try {
> > if (overrideStr != null)
> > {
> > baseValue = Long.parseLong(overrideStr);
> > }
> > } catch (NumberFormatException ex)
> > {
> > throw new RuntimeException("Could not convert number to
> > int " + overrideStr);
> > }
> >
> > return _startTime + (baseValue * 1000L);
> > }
> >
> > Thanks,
> >
>
> Rather than creating a new class, I think it would be better to
enhance the
> existing ThreadGroup, and add a new field for the duration of the
test.
>
> Or perhaps one could allow the start time to be empty, in which
case the the
> end time would be treated as a duration.
>
> Comments?
>
> S.
>
> -
> To unsubscribe, e-mail: jmeter-user-
[EMAIL PROTECTED]
> For additional commands, e-mail: jmeter-user-
[EMAIL PROTECTED]
>
--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scheduler problems
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 13:49 > To: JMeter Users List > Subject: RE: Scheduler problems > > > I'd be in favor of just changing the code. I don't think > anyone would > depend on the current behavior. > > I also think the current ThreadGroup should just be enhanced, > rather than subclassed. > OK, I've committed a change for the first part - which is to start the test even if the start-time has passed (I also made the methods private). I'll see about adding the duration enhancement soon. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scheduler problems
I'd be in favor of just changing the code. I don't think anyone would
depend on the current behavior.
I also think the current ThreadGroup should just be enhanced,
rather than subclassed.
-Mike
On 23 Oct 2003 at 13:29, BAZLEY, Sebastian wrote:
> > -Original Message-
> > From: Dave Brewster [mailto:[EMAIL PROTECTED]
> > Sent: 23 October 2003 01:56
> > To: [EMAIL PROTECTED]
> > Subject: Scheduler problems
> >
> >
> > I'm trying to develop my own listener that acts like a
> > duration scheduled thread group. I.e. the thread group runs
> > for X number of seconds.
> >
> See below - I think it would be best to enhance ThreadGroup
instead.
>
> But if you want to stop a thread, or a test directly from a sampler
or a
> listener, there are two new methods in Sampler -
setThreadStop(boolean) and
> setTestStop(boolean). These set variables which are picked up
by
> ThreadGroup.
>
> > All of this was easy to do with on exceptions. I'm running
> > into problems with the startScheduler method in JMeterThread.
> > Threads "randomly" die before they start due to the code in
> > this method the code is:
> >
> > public void startScheduler()
> > {
> > long delay = (startTime - System.currentTimeMillis());
> > if (delay > 0)
> > {
> > try
> > {
> > running = true;
> > Thread.sleep(delay);
> > }
> > catch (Exception e)
> > {
> > }
> > }
> > else
> > {
> > running = false;
> > }
> > }
> >
> > IMHO it should be changed to:
> >
> > public void startScheduler()
> > {
> > running = true;
> > long delay = (startTime - System.currentTimeMillis());
> > if (delay > 0)
> > {
> > try
> > {
> > Thread.sleep(delay);
> > }
> > catch (Exception e)
> > {
> > }
> > }
> > }
> >
> > In most (if not all?) cases one doesn't care if the start
> > time is in the past; the thread should still start.
> >
> > Thoughts? Is it possible to get this into the main line if
> > things seem fine? (I've noticed other posted around this
> > same issue as well).
> >
>
> I agree - if the start time has passed, why not start anyway?
>
> I'll see if I can get that into CVS in a day or so,
>
> Just in case anyone still wants the old behaviour, I'll make it
dependent on
> a JMeter property, which defaults to the new behaviour. [e.g.
> synchronize.start_anyway=true]
>
> >
> > The two methods I'm overriding in this class are (and it
> > extends from ThreadGroup):
> >
> > private long _startTime = 0;
> >
> > public long getStartTime() {
> > _startTime = System.currentTimeMillis();
> > return _startTime;
> > }
> >
> > /**
> >* Ends after specified duration
> >* @return
> >*/
> > public long getEndTime() {
> > long baseValue =
getProperty(TEST_DURATION).getLongValue();
> > String overrideStr =
System.getProperty(TEST_DURATION_PROP, null);
> > if (overrideStr == null)
> > {
> > overrideStr =
> > JMeterUtils.getPropDefault(TEST_DURATION_PROP, null);
> > }
> > try {
> > if (overrideStr != null)
> > {
> > baseValue = Long.parseLong(overrideStr);
> > }
> > } catch (NumberFormatException ex)
> > {
> > throw new RuntimeException("Could not convert number to
> > int " + overrideStr);
> > }
> >
> > return _startTime + (baseValue * 1000L);
> > }
> >
> > Thanks,
> >
>
> Rather than creating a new class, I think it would be better to
enhance the
> existing ThreadGroup, and add a new field for the duration of the
test.
>
> Or perhaps one could allow the start time to be empty, in which
case the the
> end time would be treated as a duration.
>
> Comments?
>
> S.
>
> -
> To unsubscribe, e-mail: jmeter-user-
[EMAIL PROTECTED]
> For additional commands, e-mail: jmeter-user-
[EMAIL PROTECTED]
>
--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scheduler problems
> -Original Message-
> From: Dave Brewster [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 01:56
> To: [EMAIL PROTECTED]
> Subject: Scheduler problems
>
>
> I'm trying to develop my own listener that acts like a
> duration scheduled thread group. I.e. the thread group runs
> for X number of seconds.
>
See below - I think it would be best to enhance ThreadGroup instead.
But if you want to stop a thread, or a test directly from a sampler or a
listener, there are two new methods in Sampler - setThreadStop(boolean) and
setTestStop(boolean). These set variables which are picked up by
ThreadGroup.
> All of this was easy to do with on exceptions. I'm running
> into problems with the startScheduler method in JMeterThread.
> Threads "randomly" die before they start due to the code in
> this method the code is:
>
> public void startScheduler()
> {
> long delay = (startTime - System.currentTimeMillis());
> if (delay > 0)
> {
> try
> {
> running = true;
> Thread.sleep(delay);
> }
> catch (Exception e)
> {
> }
> }
> else
> {
> running = false;
> }
> }
>
> IMHO it should be changed to:
>
> public void startScheduler()
> {
> running = true;
> long delay = (startTime - System.currentTimeMillis());
> if (delay > 0)
> {
> try
> {
> Thread.sleep(delay);
> }
> catch (Exception e)
> {
> }
> }
> }
>
> In most (if not all?) cases one doesn't care if the start
> time is in the past; the thread should still start.
>
> Thoughts? Is it possible to get this into the main line if
> things seem fine? (I've noticed other posted around this
> same issue as well).
>
I agree - if the start time has passed, why not start anyway?
I'll see if I can get that into CVS in a day or so,
Just in case anyone still wants the old behaviour, I'll make it dependent on
a JMeter property, which defaults to the new behaviour. [e.g.
synchronize.start_anyway=true]
>
> The two methods I'm overriding in this class are (and it
> extends from ThreadGroup):
>
> private long _startTime = 0;
>
> public long getStartTime() {
> _startTime = System.currentTimeMillis();
> return _startTime;
> }
>
> /**
>* Ends after specified duration
>* @return
>*/
> public long getEndTime() {
> long baseValue = getProperty(TEST_DURATION).getLongValue();
> String overrideStr = System.getProperty(TEST_DURATION_PROP, null);
> if (overrideStr == null)
> {
> overrideStr =
> JMeterUtils.getPropDefault(TEST_DURATION_PROP, null);
> }
> try {
> if (overrideStr != null)
> {
> baseValue = Long.parseLong(overrideStr);
> }
> } catch (NumberFormatException ex)
> {
> throw new RuntimeException("Could not convert number to
> int " + overrideStr);
> }
>
> return _startTime + (baseValue * 1000L);
> }
>
> Thanks,
>
Rather than creating a new class, I think it would be better to enhance the
existing ThreadGroup, and add a new field for the duration of the test.
Or perhaps one could allow the start time to be empty, in which case the the
end time would be treated as a duration.
Comments?
S.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scheduler problems
I agree with the idea. I had changed the code to do the same thing and
have been testing it.
It works great for me.
I think this should be changed also.
-Chris
"Dave Brewster"
<[EMAIL PROTECTED]To: <[EMAIL PROTECTED]>
ire.com> cc:
Subject: Scheduler problems
10/22/2003 08:56
PM
Please respond to
"JMeter Users
List"
I'm trying to develop my own listener that acts like a duration scheduled
thread group. I.e. the thread group runs for X number of seconds.
All of this was easy to do with on exceptions. I'm running into problems
with the startScheduler method in JMeterThread. Threads "randomly" die
before they start due to the code in this method the code is:
public void startScheduler()
{
long delay = (startTime - System.currentTimeMillis());
if (delay > 0)
{
try
{
running = true;
Thread.sleep(delay);
}
catch (Exception e)
{
}
}
else
{
running = false;
}
}
IMHO it should be changed to:
public void startScheduler()
{
running = true;
long delay = (startTime - System.currentTimeMillis());
if (delay > 0)
{
try
{
Thread.sleep(delay);
}
catch (Exception e)
{
}
}
}
In most (if not all?) cases one doesn't care if the start time is in the
past; the thread should still start.
Thoughts? Is it possible to get this into the main line if things seem
fine? (I've noticed other posted around this same issue as well).
The two methods I'm overriding in this class are (and it extends from
ThreadGroup):
private long _startTime = 0;
public long getStartTime() {
_startTime = System.currentTimeMillis();
return _startTime;
}
/**
* Ends after specified duration
* @return
*/
public long getEndTime() {
long baseValue = getProperty(TEST_DURATION).getLongValue();
String overrideStr = System.getProperty(TEST_DURATION_PROP, null);
if (overrideStr == null)
{
overrideStr = JMeterUtils.getPropDefault(TEST_DURATION_PROP, null);
}
try {
if (overrideStr != null)
{
baseValue = Long.parseLong(overrideStr);
}
} catch (NumberFormatException ex)
{
throw new RuntimeException("Could not convert number to int " +
overrideStr);
}
return _startTime + (baseValue * 1000L);
}
Thanks,
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
