jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BAZLEY, Sebastian" <Sebastian.BAZ...@london.sema.slb.com>
Subject RE: Scheduler problems
Date Thu, 23 Oct 2003 12:29:43 GMT
> -----Original Message-----
> From: Dave Brewster [mailto:dbrewster@guidewire.com]
> Sent: 23 October 2003 01:56
> To: jmeter-user@jakarta.apache.org
> 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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message