Good questions and good information. I've not exactly sorted that out quite yet. I'm in the middle of a client engagement as well as planning for a webinar on GC log file reading tomorrow night. (interested bodies can email me for signup details) so I don't expect to fully work out the details until Friday/next week. I'm guessing what I should do it prototype something and then would have to pass along the changes to see if they can be reworked back into the main branch. It would be interesting to be able to plug in new implementations of JMeterThread.
Regards, Kirk On Jun 29, 2011, at 8:38 PM, sebb wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
