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