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
|