You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Nathan J. Mehl" <jm...@memory.blank.org> on 2005/03/04 23:05:22 UTC
remote invocation almost but not quite working
I'm trying to get remote invocation of jmeter working in order to
perform a load test of my company's website, and it is almost, but not
quite actually happening.
The client (zorak) is a Windows XP SP 1 desktop with the Sun JDK 5.0 and the
Windows Firewall disabled:
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)
The server (moltar) is a RedHat 8.0 server with kernel 2.4.18-14smp,
all iptables rules set to "ACCEPT" and the Sun JDK 1.4:
java version "1.4.2_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05)
Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
Per the recent thread, I removed the "127.0.0.1" line from
c:\windows\drivers\etc\hosts on the client, and altered the
jmeter-server startup script to (a) run rmiregistry with debugging
turned up, and (b) start jmeter-server with
'-Djava.rmi.server.hostname=moltar'. "Moltar" in /etc/hosts points to
the ip address of the ethernet, not loopback interface. Moltar and
the zorak are both on the same subnet (10.1.1.0/24).
The rmiregistry starts up, and the jmeter-server appears to connect to
it, but when the client attempts to connect to the server, I see the
following in the jmeter.log file:
2005/03/04 16:52:35 INFO - jmeter.JMeter: Version 2.0.2
2005/03/04 16:52:35 INFO - jmeter.JMeter: java.version=1.5.0_01
2005/03/04 16:52:35 INFO - jmeter.JMeter: Copyright (c) 1998-2004 The Apache Software Foundation
2005/03/04 16:52:45 INFO - jmeter.gui.action.Load: Loading file: C:\Documents and Settings\nmehl\Desktop\jakarta-jmeter-2.0.2\bin\testfiles\Fundfire_Legacy_Test.jmx
2005/03/04 16:53:06 INFO - jmeter.engine.ClientJMeterEngine: about to run remote test
2005/03/04 16:53:06 INFO - jmeter.engine.ClientJMeterEngine: done initiating run command
2005/03/04 16:53:06 INFO - jmeter.engine.ClientJMeterEngine: running clientengine run method
2005/03/04 16:53:06 INFO - jmeter.engine.ConvertListeners: num threads = 6
2005/03/04 16:53:06 INFO - jmeter.engine.ConvertListeners: num threads = 6
2005/03/04 16:53:06 INFO - jmeter.engine.ClientJMeterEngine: sent host =10.1.1.248
2005/03/04 16:53:06 ERROR - jmeter.engine.ClientJMeterEngine: java.rmi.MarshalException: error marshalling arguments; nested
exception is:
java.net.SocketException: Connection reset by peer: socket write error
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at org.apache.jmeter.engine.RemoteJMeterEngineImpl_Stub.configure(Unknown Source)
at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.java:126)
at java.lang.Thread.run(Unknown Source) Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.write(Unknown Source) at
java.io.ObjectOutputStream$BlockDataOutputStream.drain(Unknown Source)
at java.io.ObjectOutputStream$BlockDataOutputStream.writeByte(Unknown Source)
at java.io.ObjectOutputStream.writeFatalException(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at sun.rmi.server.UnicastRef.marshalValue(Unknown Source)
... 4 more
On the server side, I see the following from rmiregistry (clocks are
not synced, so ignore the timestamps):
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport$ConnectionHandler run
FINE: RMI TCP Connection(2)-10.1.1.71: accepted socket from [10.1.1.71:3423]
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport$ConnectionHandler run
FINER: RMI TCP Connection(2)-10.1.1.71: (port 1099) suggesting 10.1.1.71:3423
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport$ConnectionHandler run
FINER: RMI TCP Connection(2)-10.1.1.71: (port 1099) client using 10.1.1.71:0
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport handleMessages
FINE: RMI TCP Connection(2)-10.1.1.71: (port 1099) op = 80
Mar 5, 2005 6:02:11 AM sun.rmi.transport.StreamRemoteCall getInputStream
FINER: RMI TCP Connection(2)-10.1.1.71: getting input stream
Mar 5, 2005 6:02:11 AM sun.rmi.transport.Transport serviceCall
FINER: RMI TCP Connection(2)-10.1.1.71: call dispatcher
Mar 5, 2005 6:02:11 AM sun.rmi.transport.StreamRemoteCall getOutputStream
FINER: RMI TCP Connection(2)-10.1.1.71: getting output stream
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPChannel$Reaper run
FINER: RMI ConnectionExpiration-[moltar:53098]: wake up
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPChannel freeCachedConnections
FINER: RMI ConnectionExpiration-[moltar:53098]: connection timeout expired
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPConnection close
FINE: RMI ConnectionExpiration-[moltar:53098]: close connection
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPChannel$Reaper run
FINER: RMI ConnectionExpiration-[moltar:53098]: exit
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport handleMessages
FINE: RMI TCP Connection(1)-10.1.1.248: (port 1099) connection closed
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPConnection close
FINE: RMI TCP Connection(1)-10.1.1.248: close connection
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport handleMessages
FINE: RMI TCP Connection(2)-10.1.1.71: (port 1099) op = 82
Mar 5, 2005 6:02:11 AM sun.rmi.transport.tcp.TCPTransport handleMessages
FINE: RMI TCP Connection(2)-10.1.1.71: (port 1099) op = 84
...and that is about all she wrote. Any help that the list could
offer here would be well appreciated.
-n
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of Peter Lin (woolfel@gmail.com):
> just for clarification. is you're intent to simulate
>
> 1. requests per second
> 2. concurrent users
> 3. concurrent requests
All three, but with the emphasis on #2.
The testplan is:
Thread Group: 100, 200 or 300 threads, 60-second rampup, 5 loops
|
+---> cookie manager (clear cookies each iteration)
|
+---> random controller
| |
| +---> server1 recording controller
| | |
| | +---> http request (homepage)
| | +---> http request (login)
| | +---> http request (article)
| | +---> http request (article)
| | +---> http request (article)
| | +---> http request (article)
| |
| +---> server2 recording controller (same as s1)
| +---> server3 recording controller (same as s1)
|
+---> Gaussian Random Timer (3000ms dev, 5000ms offset)
This is a slighly pessimistic expression of our company's normal
readership scenario, where our customers get an email with the day's
headlines all at the same time, log in and scan through a few
articles, and then are quiescent until the next email goes out.
(We have to use the random controller because our servers are balanced
with a simple dns roundrobin -- if we let jmeter believe dns, it'll
direct all the threads at the same server.)
> if you're testing pages that are 1k and smaller, than I you will need
> 2 or more jmeter clients running.
Hm, most of our pages are at least 3 or 4k, but can you be a be more
specific as to why this is?
-n
------------------------------------------------------------<me...@blank.org>
"Reading [James] Ellroy can be like deciphering Morse code tapped out by a
pair of barely sentient testicles." (--Dwight Garner, in _Salon_)
<http://blank.org/memory/>----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by Peter Lin <wo...@gmail.com>.
just for clarification. is you're intent to simulate
1. requests per second
2. concurrent users
3. concurrent requests
if you're trying to simulate 200, 400, 600 users, the equivalent
requests/second is going to be no more than 1/4 of the total count. In
other words.
200 users - max 50 concurrent requests
400 users - max 100 concurrent requests
600 users - max 150 concurrent requests
in this case, a 2.4 ghz system can easily generate that load. you can
look at my benchmark results for tomcat 5.5.4 with 100, 150, 200
concurrent requests for reference.
http://jakarta.apache.org/tomcat/articles/benchmark_summary.pdf
if you're testing pages that are 1k and smaller, than I you will need
2 or more jmeter clients running. hope that helps
peter
On Wed, 9 Mar 2005 14:28:53 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
> In the immortal words of sebb (sebbaz@gmail.com):
> > Doesn't one need an RMI process on each server node?
> > If not, how does the client connect to the server without an RMI process?
>
> That's actually what I was doing, e.g:
>
> tester1: rmiregistry &
> jmeter-server &
> jmeter -n -r -t mytestplan.jmx
>
> tester2: rmiregistry &
> jmeter-server
>
> I think Peter was suggesting that tester1 could run the testplan
> in-process while running it remotely on tester2 via rmi?
>
> > If you can't get this working, try using batch (non-GUI) mode on the
> > two "server" nodes.
>
> As above, that's actually what I was doing.
>
> > This uses fewer resources. Unless you need two different IP addresses,
> > you might even find that the test could be run from just the one node.
> > And the JTL files can be fairly easily combined.
>
> Hm. I don't "know" that I need both nodes -- but I'm trying to
> simulate loads of 200, 400 and 600 users on an http-request testplan
> that sequentially loads 7 urls per thread. Is it reasonable to expect
> a single server (2.4ghz P4-HT) to do that?
>
> > It helps if the various node server clocks are synchronised - even for
> > client server mode.
>
> Yeah, running ntpd everywhere. :)
>
> -n
>
> ------------------------------------------------------------<me...@blank.org>
> "We build our computers the way we build our cities -- over time, without a
> plan, on top of ruins." (--Ellen Ullman)
> <http://blank.org/memory/>----------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by sebb <se...@gmail.com>.
On Wed, 9 Mar 2005 17:53:08 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
> In the immortal words of sebb (sebbaz@gmail.com):
[if only!]
> >
> > What I meant was to copy the test plans to the two nodes, and run each
> > independently, i.e.
> >
> > jmeter -n -t mytestplan.jmx -l mytestplan.jtl
> >
> > on each node independently.
> >
> > Running the client in non-GUI mode helps, but there is still the extra
> > overhead of the RMI process and the sample results being passed back
> > to the client.
>
> Ah, okay. Is there a tool to collate two jtl files produced in this
> manner, or is it the old cut-and-paste?
If they are CSV, you can just concatenate them, and then sort on the
time - cat(1) and sort(1) on Linux would do.
If XML, you'll need to do a bit more work to merge the files, as each
has a header:
<?xml...>
and the sampleResults are wrapped in
<testResults>
</testResults>
Or analyse the files separately and then combine the analysis - e.g.
if one manages 10 requests/second and the other 20/s, the total is
30/s.
S.
> -n
>
> ----------------------------------------------------------------<me...@blank.org>
> Everyone knows history moves in circles; the surprise is how big the circles are.
> (--Greil Marcus)
> <http://blank.org/memory/>--------------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of sebb (sebbaz@gmail.com):
>
> What I meant was to copy the test plans to the two nodes, and run each
> independently, i.e.
>
> jmeter -n -t mytestplan.jmx -l mytestplan.jtl
>
> on each node independently.
>
> Running the client in non-GUI mode helps, but there is still the extra
> overhead of the RMI process and the sample results being passed back
> to the client.
Ah, okay. Is there a tool to collate two jtl files produced in this
manner, or is it the old cut-and-paste?
-n
----------------------------------------------------------------<me...@blank.org>
Everyone knows history moves in circles; the surprise is how big the circles are.
(--Greil Marcus)
<http://blank.org/memory/>--------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by sebb <se...@gmail.com>.
On Wed, 9 Mar 2005 14:28:53 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
> In the immortal words of sebb (sebbaz@gmail.com):
> > Doesn't one need an RMI process on each server node?
> > If not, how does the client connect to the server without an RMI process?
>
> That's actually what I was doing, e.g:
>
> tester1: rmiregistry &
> jmeter-server &
> jmeter -n -r -t mytestplan.jmx
>
> tester2: rmiregistry &
> jmeter-server
>
> I think Peter was suggesting that tester1 could run the testplan
> in-process while running it remotely on tester2 via rmi?
Yes, that would make sense - less overhead, as the client does not
need to communicate with a jmeter server on the same node, and there
is no need to run either RMI or the server on the same node ...
> > If you can't get this working, try using batch (non-GUI) mode on the
> > two "server" nodes.
>
> As above, that's actually what I was doing.
What I meant was to copy the test plans to the two nodes, and run each
independently, i.e.
jmeter -n -t mytestplan.jmx -l mytestplan.jtl
on each node independently.
Running the client in non-GUI mode helps, but there is still the extra
overhead of the RMI process and the sample results being passed back
to the client.
> > This uses fewer resources. Unless you need two different IP addresses,
> > you might even find that the test could be run from just the one node.
> > And the JTL files can be fairly easily combined.
>
> Hm. I don't "know" that I need both nodes -- but I'm trying to
> simulate loads of 200, 400 and 600 users on an http-request testplan
> that sequentially loads 7 urls per thread. Is it reasonable to expect
> a single server (2.4ghz P4-HT) to do that?
>
> > It helps if the various node server clocks are synchronised - even for
> > client server mode.
>
> Yeah, running ntpd everywhere. :)
>
> -n
>
> ------------------------------------------------------------<me...@blank.org>
> "We build our computers the way we build our cities -- over time, without a
> plan, on top of ruins." (--Ellen Ullman)
> <http://blank.org/memory/>----------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of sebb (sebbaz@gmail.com):
> Doesn't one need an RMI process on each server node?
> If not, how does the client connect to the server without an RMI process?
That's actually what I was doing, e.g:
tester1: rmiregistry &
jmeter-server &
jmeter -n -r -t mytestplan.jmx
tester2: rmiregistry &
jmeter-server
I think Peter was suggesting that tester1 could run the testplan
in-process while running it remotely on tester2 via rmi?
> If you can't get this working, try using batch (non-GUI) mode on the
> two "server" nodes.
As above, that's actually what I was doing.
> This uses fewer resources. Unless you need two different IP addresses,
> you might even find that the test could be run from just the one node.
> And the JTL files can be fairly easily combined.
Hm. I don't "know" that I need both nodes -- but I'm trying to
simulate loads of 200, 400 and 600 users on an http-request testplan
that sequentially loads 7 urls per thread. Is it reasonable to expect
a single server (2.4ghz P4-HT) to do that?
> It helps if the various node server clocks are synchronised - even for
> client server mode.
Yeah, running ntpd everywhere. :)
-n
------------------------------------------------------------<me...@blank.org>
"We build our computers the way we build our cities -- over time, without a
plan, on top of ruins." (--Ellen Ullman)
<http://blank.org/memory/>----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by sebb <se...@gmail.com>.
Doesn't one need an RMI process on each server node?
If not, how does the client connect to the server without an RMI process?
==
If you can't get this working, try using batch (non-GUI) mode on the
two "server" nodes.
This uses fewer resources. Unless you need two different IP addresses,
you might even find that the test could be run from just the one node.
And the JTL files can be fairly easily combined.
It helps if the various node server clocks are synchronised - even for
client server mode.
S.
On Wed, 09 Mar 2005 08:50:07 -0500, Michael Stover <ms...@apache.org> wrote:
> Also, try adding a -l entry (ie -l testlog.log).
>
> -Mike
>
> On Tue, 2005-03-08 at 23:18, Nathan J. Mehl wrote:
> > In the immortal words of Peter Lin (woolfel@gmail.com):
> > > it's pretty hard to figure out what is happening based on the errors.
> > > Just to clarify, do you have 2 RMI servers setup or 1. Normally, only
> > > one is needed. Having two RMI servers might cause weird problems, but
> > > I'm not an expert.
> >
> > Hm, okay, that was unclear from the docs -- yes, I'd set up two rmi
> > servers, e.g.:
> >
> > remote_hosts=10.1.1.166,10.1.1.167
> >
> > ...and run rmiregisitry+jmeter-server on both, and then run jmeter -rn
> > from a different shell on the first host.
> >
> > I'll give it a shot with RMI only running on the second host; I assume
> > that would be set up as:
> >
> > remote_hosts=127.0.0.1,10.1.1.167
> >
> > ...?
> >
> > > by any chance do the systems have multiple IP address and multiple
> > > ethernet ports?
> >
> > No and no, sorry. :/
> >
> > -n
> >
> > ------------------------------------------------------------<me...@blank.org>
> > "A Force Recon colonel once told me, "If it's a stupid idea, and it works, it
> > must not be a stupid idea." (--John Frazier)
> > <http://blank.org/memory/>----------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> --
> Michael Stover <ms...@apache.org>
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by Michael Stover <ms...@apache.org>.
Also, try adding a -l entry (ie -l testlog.log).
-Mike
On Tue, 2005-03-08 at 23:18, Nathan J. Mehl wrote:
> In the immortal words of Peter Lin (woolfel@gmail.com):
> > it's pretty hard to figure out what is happening based on the errors.
> > Just to clarify, do you have 2 RMI servers setup or 1. Normally, only
> > one is needed. Having two RMI servers might cause weird problems, but
> > I'm not an expert.
>
> Hm, okay, that was unclear from the docs -- yes, I'd set up two rmi
> servers, e.g.:
>
> remote_hosts=10.1.1.166,10.1.1.167
>
> ...and run rmiregisitry+jmeter-server on both, and then run jmeter -rn
> from a different shell on the first host.
>
> I'll give it a shot with RMI only running on the second host; I assume
> that would be set up as:
>
> remote_hosts=127.0.0.1,10.1.1.167
>
> ...?
>
> > by any chance do the systems have multiple IP address and multiple
> > ethernet ports?
>
> No and no, sorry. :/
>
> -n
>
> ------------------------------------------------------------<me...@blank.org>
> "A Force Recon colonel once told me, "If it's a stupid idea, and it works, it
> must not be a stupid idea." (--John Frazier)
> <http://blank.org/memory/>----------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
--
Michael Stover <ms...@apache.org>
Apache Software Foundation
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of Peter Lin (woolfel@gmail.com):
> it's pretty hard to figure out what is happening based on the errors.
> Just to clarify, do you have 2 RMI servers setup or 1. Normally, only
> one is needed. Having two RMI servers might cause weird problems, but
> I'm not an expert.
Hm, okay, that was unclear from the docs -- yes, I'd set up two rmi
servers, e.g.:
remote_hosts=10.1.1.166,10.1.1.167
...and run rmiregisitry+jmeter-server on both, and then run jmeter -rn
from a different shell on the first host.
I'll give it a shot with RMI only running on the second host; I assume
that would be set up as:
remote_hosts=127.0.0.1,10.1.1.167
...?
> by any chance do the systems have multiple IP address and multiple
> ethernet ports?
No and no, sorry. :/
-n
------------------------------------------------------------<me...@blank.org>
"A Force Recon colonel once told me, "If it's a stupid idea, and it works, it
must not be a stupid idea." (--John Frazier)
<http://blank.org/memory/>----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: random remote invocation failures
Posted by Peter Lin <wo...@gmail.com>.
it's pretty hard to figure out what is happening based on the errors.
Just to clarify, do you have 2 RMI servers setup or 1. Normally, only
one is needed. Having two RMI servers might cause weird problems, but
I'm not an expert.
by any chance do the systems have multiple IP address and multiple
ethernet ports?
peter
On Tue, 8 Mar 2005 19:18:18 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
>
> Okay, this is driving me quite mad.
>
> I have a testplan that I want to run against a set of webservers. I
> have two dedicated testing hosts, running RedHat Fedora 3 with the Sun
> jdk1.4.2 installed.
>
> Each testing server is configured to run rmiregistry and
> jmeter-server. The first server (tester1) has its own IP address and
> tester2's ip address specified in jmeter.properties, and I'm starting
> things off on tester1 with:
>
> ./jmeter -r -n -t web_200user_5cycle.jmx
>
> SOMETIMES... this works. Jmeter runs, it connects to the two rmi
> listeners, and executes the testplan on the two servers.
>
> OTHER times... this fails with the following inscrutable error on the
> client:
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
random remote invocation failures
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
Okay, this is driving me quite mad.
I have a testplan that I want to run against a set of webservers. I
have two dedicated testing hosts, running RedHat Fedora 3 with the Sun
jdk1.4.2 installed.
Each testing server is configured to run rmiregistry and
jmeter-server. The first server (tester1) has its own IP address and
tester2's ip address specified in jmeter.properties, and I'm starting
things off on tester1 with:
./jmeter -r -n -t web_200user_5cycle.jmx
SOMETIMES... this works. Jmeter runs, it connects to the two rmi
listeners, and executes the testplan on the two servers.
OTHER times... this fails with the following inscrutable error on the
client:
2005/03/08 19:08:57 WARN - jmeter.engine.ClientJMeterEngine: Error replacing
sample listeners java.lang.IndexOutOfBoundsException: Index: -1, Size: 7
at java.util.LinkedList.entry(LinkedList.java:360)
at java.util.LinkedList.set(LinkedList.java:317)
at org.apache.jorphan.collections.ListedHashTree.replace(ListedHashTree.java:133)
at org.apache.jmeter.engine.ConvertListeners.addNode(ConvertListeners.java:76)
at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:1011)
at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:990)
at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.java:115)
at java.lang.Thread.run(Thread.java:534)
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent host =69.44.125.166
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent host =69.44.125.167
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent test
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent run command
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent test
2005/03/08 19:08:57 INFO - jmeter.engine.ClientJMeterEngine: sent run command
...and on the servers:
java.lang.NullPointerException
at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:1012)
at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:1012)
at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:990)
at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:330)
When this happens, the client sits and spins, and nothing happens on
the servers.
...and yet OTHER times, the client fails immediately with the following error
looping in the log:
2005/03/08 19:15:52 INFO - jmeter.JMeter: Version 2_0.20050306
2005/03/08 19:15:53 INFO - jmeter.JMeter: java.version=1.4.2_07
2005/03/08 19:15:53 INFO - jmeter.JMeter: Copyright (c) 1998-2005 The Apache Software Foundation
2005/03/08 19:15:53 INFO - jmeter.JMeter: Loading file: Ignites_legacy_200_5.jmx
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: about to run remote test
2005/03/08 19:15:53 IN2005/03/08 19:15:53 INFO - jmeter.engine.RemoteJMeterEngineImpl: received host: 69.44.125.166
jmeter.engine.ClientJMeterEngine: running clientengine run method
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: about to run remote test
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: done initiating run command
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: running clientengine run method
2005/03/08 19:15:53 INFO - jmeter.engine.ConvertListeners: num threads = 100
2005/03/08 19:15:53 INFO - jmeter.engine.ConvertListeners: num threads = 100
2005/03/08 19:15:53 INFO - jmeter.engine.ConvertListeners: num threads = 100
2005/03/08 19:15:53 INFO - jmeter.engine.ConvertListeners: num threads = 100
2005/03/08 19:15:53 WARN - jmeter.engine.ClientJMeterEngine: Error replacing sample listeners java.lang.IndexOutOfBoundsException: Index: -1, Size: 7
at java.util.LinkedList.entry(LinkedList.java:360)
at java.util.LinkedList.set(LinkedList.java:317)
at org.apache.jorphan.collections.ListedHashTree.replace(ListedHashTree.java:133)
at org.apache.jmeter.engine.ConvertListeners.addNode(ConvertListeners.java:76)
at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:1011)
at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:990)
at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.java:115)
at java.lang.Thread.run(Thread.java:534)
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: sent host =69.44.125.166
2005/03/08 19:15:53 INFO - jmeter.engine.ClientJMeterEngine: sent host =69.44.125.167
2005/03/08 19:15:54 ERROR - jmeter.engine.ClientJMeterEngine: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.OptionalDataException
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:292)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
at org.apache.jmeter.engine.RemoteJMeterEngineImpl_Stub.configure(Unknown Source)
at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.java:126)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.OptionalDataException
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:249)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
... 1 more
Caused by: java.io.OptionalDataException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.util.HashMap.readObject(HashMap.java:1005)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1810)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1772)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.util.HashMap.readObject(HashMap.java:1006)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:297)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:246)
... 6 more
2005/03/08 19:15:54 ERROR - jmeter.engine.ClientJMeterEngine: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.OptionalDataException
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:292)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
at org.apache.jmeter.engine.RemoteJMeterEngineImpl_Stub.configure(Unknown Source)
at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.java:126)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.OptionalDataException
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:249)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
... 1 more
Caused by: java.io.OptionalDataException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.util.HashMap.readObject(HashMap.java:1005)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1810)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1772)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.util.HashMap.readObject(HashMap.java:1006)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:297)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:246)
... 6 more
When this condition occurs, the servers give no errors.
...and there seems to be no predictability whatsoever about when the
errors happen and when the testplan executes.
The errors happen at the same frequency in both the 2.0.2 release and
the latest nightly snapshot.
Er, help?
-n
-------------------------------------------------------------<me...@blank.org>
"This brings up the interesting problem that is all-pervasive in driving games
-- that San Francisco is seen as the best city in which to drive. Of course
the jumps are cool, but the harsh reality (and we at DailyRadar.com live there)
is that driving in San Francisco sucks ass. You can't turn left anywhere, ever,
and if you want to get to the Marina district, you have to be born there. It is
pretty though." (--Frank O'Connor)
<http://blank.org/memory/>-----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: remote invocation almost but not quite working
Posted by Peter Lin <wo...@gmail.com>.
if you load the JTL in the nightly build, you can save the graph as a PNG.
it's been in JMeter head since last summer
peter
On Tue, 8 Mar 2005 15:49:23 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
> In the immortal words of sebb (sebbaz@gmail.com):
> >
> > > One last, possibly dumb question: the component reference mentions
> > > that listeners can save their data to a csv or xml file for future
> > > reviewing. What it does not mention is how you would load the stl
> > > file back into a listener to look at -- and none of the listeners
> > > appear to have any obvious control to do this with...?
> >
> > Create a dummy test plan with the appropriate listener(s) in it. Then
> > use the file browse box to open the file, and it should be loaded by
> > the listener. Not sure if all the listeners can handle CSV input
> > though.
>
> Ah, just so, thanks.
>
> Is there any way to save the output of the "graph results" controller
> as a jpg/png/etc file?
>
> -n
>
> ------------------------------------------------------------<me...@blank.org>
> "We build our computers the way we build our cities -- over time, without a
> plan, on top of ruins." (--Ellen Ullman)
> <http://blank.org/memory/>----------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: remote invocation almost but not quite working
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of sebb (sebbaz@gmail.com):
>
> > One last, possibly dumb question: the component reference mentions
> > that listeners can save their data to a csv or xml file for future
> > reviewing. What it does not mention is how you would load the stl
> > file back into a listener to look at -- and none of the listeners
> > appear to have any obvious control to do this with...?
>
> Create a dummy test plan with the appropriate listener(s) in it. Then
> use the file browse box to open the file, and it should be loaded by
> the listener. Not sure if all the listeners can handle CSV input
> though.
Ah, just so, thanks.
Is there any way to save the output of the "graph results" controller
as a jpg/png/etc file?
-n
------------------------------------------------------------<me...@blank.org>
"We build our computers the way we build our cities -- over time, without a
plan, on top of ruins." (--Ellen Ullman)
<http://blank.org/memory/>----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: remote invocation almost but not quite working
Posted by sebb <se...@gmail.com>.
On Mon, 7 Mar 2005 20:17:16 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
[...]
> One last, possibly dumb question: the component reference mentions
> that listeners can save their data to a csv or xml file for future
> reviewing. What it does not mention is how you would load the stl
> file back into a listener to look at -- and none of the listeners
> appear to have any obvious control to do this with...?
Create a dummy test plan with the appropriate listener(s) in it. Then
use the file browse box to open the file, and it should be loaded by
the listener. Not sure if all the listeners can handle CSV input
though.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: remote invocation almost but not quite working
Posted by "Nathan J. Mehl" <jm...@memory.blank.org>.
In the immortal words of sebb (sebbaz@gmail.com):
> On Fri, 4 Mar 2005 17:05:22 -0500, Nathan J. Mehl
> <jm...@memory.blank.org> wrote:
> >
> > I'm trying to get remote invocation of jmeter working in order to
> > perform a load test of my company's website, and it is almost, but not
> > quite actually happening.
> > 2005/03/04 16:52:35 INFO - jmeter.JMeter: Version 2.0.2
> > 2005/03/04 16:52:35 INFO - jmeter.JMeter: java.version=1.5.0_01
> > 2005/03/04 16:52:35 INFO - jmeter.JMeter: Copyright (c) 1998-2004 The Apache Software Foundation
> > 2005/03/04 16:52:45 INFO - jmeter.gui.action.Load: Loading file: C:\Documents and Settings\nmehl\Desktop\jakarta-jmeter-2.0.2\bin\testfiles\Fundfire_Legacy_Test.jmx
>
> It's a known bug that JMeter remote does not work if JMeter is
> installed in a directory containing spaces. I suspect that's the cause
> here.
Huh, how odd. That was, in fact, the case -- thanks very much.
One last, possibly dumb question: the component reference mentions
that listeners can save their data to a csv or xml file for future
reviewing. What it does not mention is how you would load the stl
file back into a listener to look at -- and none of the listeners
appear to have any obvious control to do this with...?
-n
------------------------------------------------------------<me...@blank.org>
"The beauty you like is precisely that which escapes you." (--Issey Miyake)
<http://blank.org/memory/>----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: remote invocation almost but not quite working
Posted by sebb <se...@gmail.com>.
On Fri, 4 Mar 2005 17:05:22 -0500, Nathan J. Mehl
<jm...@memory.blank.org> wrote:
>
> I'm trying to get remote invocation of jmeter working in order to
> perform a load test of my company's website, and it is almost, but not
> quite actually happening.
> 2005/03/04 16:52:35 INFO - jmeter.JMeter: Version 2.0.2
> 2005/03/04 16:52:35 INFO - jmeter.JMeter: java.version=1.5.0_01
> 2005/03/04 16:52:35 INFO - jmeter.JMeter: Copyright (c) 1998-2004 The Apache Software Foundation
> 2005/03/04 16:52:45 INFO - jmeter.gui.action.Load: Loading file: C:\Documents and Settings\nmehl\Desktop\jakarta-jmeter-2.0.2\bin\testfiles\Fundfire_Legacy_Test.jmx
It's a known bug that JMeter remote does not work if JMeter is
installed in a directory containing spaces. I suspect that's the cause
here.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org