On 29 June 2011 12:14, Kirk <kirk.pepperd...@gmail.com> wrote: > So, I've been looking into implementing a new style of thread group that > supports my recent views regarding the closed system vs open system nature of > load testing harnesses. Unfortunately I see that JMeterThread is referenced > in; > > AbstractThreadGroup > public abstract void scheduleThread(JMeterThread thread); > > > JMeterContext > private JMeterThread thread; with get and set > > > JMeterThreadMonitor > public void threadFinished(JMeterThread thread); > > > StandardJMeterEngine > private final Map<JMeterThread, Thread> allThreads; along with a bunch of > other places. > > ThreadGroup > expected but nicely confined to only two methods public void > scheduleThread(JMeterThread thread) > > > ThreadListener > SamplePackage pack = (SamplePackage) > threadVars.getObject(JMeterThread.PACKAGE_OBJECT); > > > WhileController > res = > "false".equalsIgnoreCase(threadVars.get(JMeterThread.LAST_SAMPLE_OK));// > $NON-NLS-1$ >
These last two are merely constants, so should not cause any problems. > I would need a JMeterThread like object but it would be some what different > than JMeterThread. It's not a subclass as there is stuff in JMeterThread that > I wouldn't want. As is often the case when one first tries to extend a > framework, there will need to be some refactorings to support my new thread > group. > > So question is, how to proceed? (or to proceed at all) What are the features of JMeterThread that you don't want? It might be possible to extract a common interface that would suit both sets of code. Bigger question - how are you proposing to implement the different behaviour? Also, note that the JMeter code currently assumes that each sampler thread is a Java thread. Variables etc. are accessed via ThreadLocal. > Regards, > Kirk > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
