You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Patrick Onyeyiri <Pa...@corizon.com> on 2005/08/26 12:45:51 UTC
[PATCH] A "Thread Watcher" Listener
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
Re: [PATCH] A "Thread Watcher" Listener
Posted by sebb <se...@gmail.com>.
Thanks!
Unfortunately, the attachment did not arrive.
Please could you create a Bugzilla issue, and attach the file to that?
[Can only attach once the issue has been created].
See http://issues.apache.org/bugzilla/enter_bug.cgi?product=JMeter
S.
On 26/08/05, Patrick Onyeyiri <Pa...@corizon.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: [PATCH] A "Thread Watcher" Listener
Posted by sebb <se...@gmail.com>.
By the way, the beanshell server allows remote access to JMeter over
telnet or http (if enabled!).
Might be useful for non-GUI runs.
S.
On 26/08/05, Michael Stover <ms...@apache.org> wrote:
> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: [PATCH] A "Thread Watcher" Listener
Posted by Michael Stover <ms...@apache.org>.
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org