Hi again,
I've managed to solve the problem: it was indeed an errornous hosts file on the remote machine. The host file just had no entry for the external IP but instead assigned the 127.0.0.1 IP to the hostname.
This leaves room for speculation why the client tries to talk to the 127.0.0.1 IP - to my mind this IP must be coming from the remote machine although that wouldn't make sense.
After fixing the hosts file, I received a java.rmi.MarshalException. Fortunatly, that problem was already discussed on this list and the solution for me was to ensure that both systems use exactly the same JARs.
I've put up the HostInfo-Javatool under the following address: http://metrixon.de/files/HostInfo.java (and for convenience: http://metrixon.de/files/HostInfo.class)
The class will print out the hostname and IP of the localhost and any other hostname specified on the command line. It will also check if there are security permissions set concerning the getLocalHost() call (while trying to solve my problem, I came across the fact that the getLocalHost() call will return the loopback IP address (127.0.0.1) in case security permissions disallow a connection).
Maybe it can be of help to anyone else.
Thanks again,
Christian
sebb wrote:
On Thu, 28 Oct 2004 01:28:35 +0200, Christian Schwanke <[EMAIL PROTECTED]> wrote:
Interesting that the server log changes on different systems. I can't say I've looked at them closely, because we never use remote mode - non-GUI (batch) is a lot more efficient.
OK, maybe I'll consider this as well - but that would be workaround not a solution ;-)
Depends - it's definitely the solution at present if you want to run
high throughput tests.
But I still don't understand why the *client* should be trying to connect to 127.0.0.1.
I think, the remote machine that is run in server mode tries to determine its own IP by calling "InetAddress.getLocalHost().getHostName()" (sorry, wrote the wrong API call in the previous mail - this code is in "RemoteJMeterEngineImpl.java", line 48). Within my test environment, the server machine receives "127.0.0.1" as result to the getHostName() call. What exactly happens behind the RMI scenes I don't know - I suppose, the server machine will propagate its own IP to the client (gui) machine. This would explain, why the client tries to connect to the 127.0.0.1-Address (The client/server-conversion could be something like this: client: "server xyz are you there ?" server: "yep, I'm here and you can reach me at 127.0.0.1". As I've said before, I don't know how RMI exactly works so this is pure speculation ;-))
I don't think that is the case. The client knows the hostname or IP of the RMI server, and connects to the RMI port on that server.
What does the client log say on the working system? What if you run the client on the working system, but fail to start the server on the other working system?
But should the server really propagate the IP, there should be a slicker way of handling the remote calls. It wouldn't make sense to tell the client the exact IP address of the remote machine, if the remote machine sends its IP in return (that's like calling someone on the phone and asking him for his/her phonenumber).
Indeed - I don't think this happens.
Maybe the idea to incorporate something like JRendezvous could be helpful here (I came across that idea reading through the wiki).
Anyway, in my case, even JRendezvous wouldn't be of much help, since the IP/DNS configration of the server machine seems to be errornous. I've written a small java class to print out the hostname and address, that the InetAddress-API will return - I think this should clear up this issue. I'll certainly consider your idea of comparing the host files to further investigate.
Regards, Christian
I tracked this down within the source files. To my mind, the call to INetAddress.getLocalHost().getHostAddress() seems to return not the external IP but the loopback IP.
Which source file is this?
I know this is somewhat of the scope of this mailing list, but maybe someone has got an idea, what may cause this behaviour. Could be the host-file on the server-machine ?
Perhaps? Can you compare them?
---------------------------------------------------------------------Anyway, thanks for your help. Regards. christian
Am 27.10.2004 um 18:38 schrieb sebb:
On Wed, 27 Oct 2004 18:07:56 +0200 (MEST), Christian Schwanke <[EMAIL PROTECTED]> wrote:
Hi, I successfully ran a testplan locally. Now I want to run the testplan on a remote machine. I followed the instructions from the manual and started the jmeter-server--Skript (which - as I understand - launches the rmiregistry).
Yes, it launches both the registry and the jmeter server
The log file on the remote machine states: 2004/10/27 18:10:27 INFO - jmeter.JMeter: Version 2.0.1 2004/10/27 18:10:27 INFO - jmeter.JMeter: java.version=1.4.2 2004/10/27 18:10:27 INFO - jmeter.engine.RemoteJMeterEngineImpl: Starting backing engine 2004/10/27 18:10:27 DEBUG - jmeter.engine.RemoteJMeterEngineImpl: This = org.apache.jmeter.engine.RemoteJMeterEngineImpl[RemoteStub [ref: [endpoint:[127.0.0.1:54315](local),objID:[0]]]]
Remark: I'm not sure wether the 127.0.0.1 is correct here ?
I then launched the JMeter-Client on my local machine specifying the remote host name of the server in the properties-file (remote_hosts-property). the GUI offers the correct hostname within the remote start-submenu. However, when commencing a remote test, the following error is logged locally:
2004/10/27 18:00:23 ERROR - jmeter.engine.ClientJMeterEngine: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
This looks wrong - the client should try to connect to the remote system. Could be an error in the remote_hosts property, or perhaps a DNS resolution error.
Or did you perhaps leave in the 127.0.0.1 entry and do a remote start all?
What does jmeter.log say just before this error? It might say what host name it was trying to use.
java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.apache.jmeter.engine.RemoteJMeterEngineImpl_Stub.setHost(Unknown Source) at org.apache.jmeter.engine.ClientJMeterEngine.run(ClientJMeterEngine.j av a:136) at java.lang.Thread.run(Unknown Source)
I'm pretty sure that there is a simple solution to this problem, but I just can't figure it out. I don't know much about RMI, e.g. if I need to start a rmiregistry locally as well.
I don't think so.
Any advice is appreciated,
Thanks, Christian
-------------------------------------------------------------------- - 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]
--------------------------------------------------------------------- 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]
