jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Salvat i Alabart <jsalv...@atg.com>
Subject Re: Scheduler problems
Date Thu, 23 Oct 2003 23:09:28 GMT
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: 	mstover1@apache.org [mailto:mstover1@apache.org] 
> 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: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
> 
> 
> 
> 
> 
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
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