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]
