Of course. There is always this slight disconnect from what we code for ourselves, and what code works best for everyone, and it's just a question of how we structure what you've implemented.
-Mike On Fri, 2005-08-26 at 15:58 +0100, Patrick Onyeyiri wrote: > Yeah, I think putting an interface over the engine would be a better > idea. And I created a bug report: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=36378 > > I also like the idea of it being separate from the listeners - its just > that I was doing a little custom feature, then decided that others may > like it. > > -Nnamdi > > -----Original Message----- > From: Michael Stover [mailto:[EMAIL PROTECTED] > Sent: 26 August 2005 15:34 > To: JMeter Dev List > Subject: Re: [PATCH] A "Thread Watcher" Listener > > This is really interesting, and I think we'd very much like to > see/incorporate this code. I'm a little worried about #1, however. I'm > not sure I like the idea of passing the whole engine to all the > listeners. Maybe a new interface could be written that defines a > limited interface that the StandardEngine could implement. > > Also, I'm not sure that this should be part of the listeners. I'm > thinking it could be a new element that watches the engine/threads. It > could even be something JMeter dynamically adds to the test tree when > the test is run, allowing users all these neat controls over the test > during runtime (start/stop/pause threads). > > I think your attached patch was stripped by the mailing list - you > should open a bugzilla bug and create an attachment there. > > -Mike > > On Fri, 2005-08-26 at 11:45 +0100, Patrick Onyeyiri wrote: > > I was asked by somebody in the office to extend JMeter so that when > > running tests, and threads stop (due to failure) to make a way to > > restart the thread. What I have done is to create a new Visualizer > that > > lists all the running threads, and allows you to right click on them > in > > the list and stop/restart them. However, this required a few changes > to > > the way JMeter works. > > > > > > > > 1. When the initial parsing of the test tree occurs, a new > > traverser was added that passed an instance of the engine being used > to > > all test plan tree objects that are derived from AbstractVisualizer. > > 2. AbstractVisualizer was extended to receive the engine instance. > > 3. StandardJMeterEngine was extended to be able to restart threads, > > and accept JMeterEngineMonitors. > > 4. JMeterThread was extended to fire events to JMeterThreadMonitor > > (which was also extended) to indicate when it started. > > 5. A new class JMeterEngineMonitor was created to monitor when > > engines create threads, when their threads are stopped, and when the > > test starts/stops. > > 6. New visualizer class ThreadWatcherVisualizer, and > > ThreadWatcherTableDataModel were created for the GUI. > > 7. messeages.properties was modified to add the extra strings for > > the visualizer. > > > > > > > > > > > > The visualizer is used by addeding it to the test plan, then when a > test > > is running, you can see/change the running status of all the threads. > > When all threads are stopped - the test stops. I have attached a > patch > > file to this email. > > > > > > > > - Nnamdi > > > > > > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
