Re: Scheduler problems

Thu, 23 Oct 2003 16:08:20 -0700

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]

Reply via email to