File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Distributed Java and the fly likes RMI problem on Linux Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "RMI problem on Linux" Watch "RMI problem on Linux" New topic
Author

RMI problem on Linux

Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Hello:
I've run my RMI app on Windows 98, NT, XP, and on Solaris. It doesn't matter if the client or the server is on any of these it always works great. When running on Linux, it works fine if the client is on Linux and the server is on any of the others, but if the server is on Linux, when I try to connect the client, I get:
java.rmi.ConnectException: Connection refused to host: 0.0.0.0; nested exception is:
java.net.ConnectException: Connection refused: connect
everytime. Does anyone have any ideas what may be causing this? Does it have something to do with Linux having a firewall....or what? I am at a total loss. If you don't know...any ideas how I can troubleshoot it? I know it's nothing simple like wrong IP or bad paths or filesystem delimiters or anything like that.

With Respect,
Matt
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Oh,
The other thing is, in this case, both the client and the server machines are on my local home network. Note again that if the client is running on Linux and the server is running on XP, it works fine. I am using the IP address and not the name of the machine to connect. Is it maybe a DNS problem? How do I resolve it?

With Respect,
Matt
[ June 25, 2002: Message edited by: Matt DeLacey ]
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
One last thing
On the Linux side, I'm using Java SDK 1.4.0.
All other JVMs I've used have been 1.3.1 or less. Could that be the problem?

With Respect,
Matt
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Salam,
Are you getting this error when looking up the stub, or when using the stub to perform a remote call ?


Omar IRAQI Houssaini
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
That is something unexpected. When I look up the stub I see no problems...I even catch Exception....no problems. It's when I first try to use the stub to perform a remote call.
With Respect,
Matt
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

If you're running RedHat, look at /etc/sysconfig/ipchains - that's where the firewall rules would usually be. I assume you're not running iptables. If you used the GUI install, chances are that only a few ports like the HTTP port (80) and FTP ports are configured to accept traffic.
I've got a hand-rolled set, and violators get reported to the syslog (/etc/messages) file, but that requires an explicit option on each rejecting rule.


Customer surveys are for companies who didn't pay proper attention to begin with.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

One reason RMI isn't more popular is, in fact, that it runs through a tcp/ip port that is considered "dangerous" and thus often firewalled out on the Inernet at large. EJBs, being RMI objects themselved are subject to the same problem, which is why it's "easier" to write a web app using layers of jsps/servlets and EJBs than to expect a client/server RMI app to function universally. SOAP is another way to to RPCs in a firewalled world.
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Tim:

Great! Thanks for the info. I AM Running Red Hat (7.1 I think) and I DID do a GUI install, so I guess that's it. I'm pretty new to Linux so can you tell me what I need to change in those system files such that port 1099 is okay to run RMI on?

With Respect,
Matt
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Hi Matt,
I don't agree with Tim about his interpretation. From the error that you get (Connection refused to 0.0.0.0), the problem is definitly not due to firewall filtering.
Here is my interpretation :
The stub object is fetched successfully, and as you know the stub contains enough info to let the client do remote invocation. One info is the IP address of the server on which the RMI implementation is running. So far so good, however here problems start : The stub that your client fetches contains a bad IP address : 0.0.0.0 instead of YOUR_SERVER_IP, meaning that a problem occured at the binding time due to a bad IP configuration on your linux machine.
To make sure of this, try to print the stub object after looking it up, you will see : 0.0.0.0 within the printed string.
Please, confirm or reject my interpretation, and then we can see what to do next, basically how to configure networking parameters on Linux.
Regards
[ June 27, 2002: Message edited by: Omar IRAQI ]
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Omar:
Thanks a bunch. You are correct. I suspect I will have troubles with the things Tim has brought up, but you are right in that the stub does not have the correct IP address (it has 0.0.0.0). You know I made that stub on an NT box. Do you think I need to create the stub on Linux? Or possibily it DOES have something to do with the ports being locked down. This is interesting. I guess I need to create the stub on Linux and then ship over to the client side.
What do you think?
With Respect,
leanmattie
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Acutally, I wasn't saying that the problem WAS firewalling, just making some observations.
Java is supposed to be write-once/run-anywhere. I know of no reason why it should matter what OS you generated the stub or skeleton on. In fact, it would defeat the purpose.
It sounds like a problem with retrieving the context. To invoke an RMI process, the RMI server has to register with a registry server (typically running on port 1099). Among the things registered in that process should be the RMI server's IP address. When the client wishes to invoke the RMI service, it does a lookup against that same RMI registry server (this is NOT a distributed service, so it DOES have to be the SAME registry server that the RMI server registered on!). That lookup should return everything needed.
So the things I would check are 1) make sure that you're querying the right registry server and 2) make sure that you're not inadvertently losing a complaint (exception or failuare code) made by either the client or server.
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Matt, hello again
Possible causes :
1- bad IP configuration on your linux machine.
2- 1, and nothing else.
Login as root, and from the console run : ifconfig > toto
Reply with the content of the file "toto".
Regards
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
This is to correct something that was said by Tim : "RMI runs through a tcp/ip port that is considered "dangerous" " !!!
Is the port that is dangerous or the application itself that listens at this port that is dangerous !!!?
Assume that you run a HTTP server that listens at port 1099. So would 1099 be still dangerous ?
Assume now that you run The RMIRegistry on 80. Would 80 be safe ?
The thing is that, most Firewall admins, open only a very limited number of ports to limit their internal system exposure.
THERE IS NOTHING CALLED DANGEROUS TCP PORT. All ports are seen exactly the same way by the TCP protocol.
Regards
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Omar:
eth0 Link encap:Ethernet HWaddr 00:10:B5:3E:19:EF
inet addr:[The number here is the same that I type to access the server]Bcast:4.46.227.255 Mask:255.255.252.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:2116 errors:0 dropped:0 overruns:0 frame:0
TX packets:917 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:289753 (282.9 Kb) TX bytes:89904 (87.7 Kb)
Interrupt:9 Base address:0xf000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:277 errors:0 dropped:0 overruns:0 frame:0
TX packets:277 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21195 (20.6 Kb) TX bytes:21195 (20.6 Kb)

With Respect,
Matt
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Matt,
The config of eth0 seems to be fine
Let us see the content of /etc/hosts
Regards
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Also, when you issue :
ping localhost
on your linux machine
1-do u get the reply from 127.0.0.1 ?
2-do u get the reply from [linux_machine_IP]?
3-no reply at all
Regards
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Omar:
Thanks for your help. When I ping localhost, I get a reply from 127.0.0.1.
/etc/hosts just has one entry:
127.0.0.1 localhost.localdomain localhost

With Respect,
Matt
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Hi Matt,
As we have already mentioned, the stub contains the IP address of the endpoint where the implementation is running.
When the method Naming.rebind() is executed on your linux machine, the RMIRegistry builds the corresponding stub and issues a system call to get the IP address of the localhost (the alias localhost is VERY IMPORTANT here) to associate it with that stub.
Under linux system, the IP address of the localhost is mapped from /etc/hosts file. This is why, you should overwrite 127.0.0.1 with [YOUR_SERVER_IP_ADDRESS].
try a new <ping localhost> to make sure the modification has taken place, and reexecute your app.
Waiting for your feedbabk.
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Well, I made the change to /etc/hosts, then I did ping localhost and saw that it was correct, but then ran my app, and saw the same behavior. Thanks for all your help though. This problem is a bugger.
With Respect,
Matt
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Assuming you restarted the server after you made the change?
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Yes, but thanks for the suggestion.
I'm thinking now that it has to do with the fact that I'm running the server on Java SDK 1.4 whereas everything else has been either 1.2.2 or 1.3. Maybe it's a bug in 1.4?
With Respect,
Matt
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Did you happen to try a simple, "hello world" server/client test? Writing the test should only take about 10 minutes. If that works on 1.3, but fails to work on 1.4, then you can be certain the problem is a 1.4 bug.


Java Regular Expressions
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
That's a good idea Max. I will try it. Thanks!

With Respect,
Matt DeLacey
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
Thanks to all for your help on this one. I have some VERY interesting news. I was thinking perhaps the reason was that I was using jsdk1.4 on Linux and I wasn't sure if all the bugs had been worked out of 1.4.

Well, I downloaded 1.3.1 and all other things being equal, it worked!!! Looks like there is some problem with 1.4 if Linux is running the server in an RMI app.

With Respect,
Matt
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Release notes For Linux.

"A deployed J2EE client on Windows or Solaris cannot connect to J2EE on a default installation of Redhat Linux. The Redhat Linux method InetAddress.get LocalHost() returns the loopback address instead of the actual host address. "
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
This isn't J2EE, but I guess that is what is going on nonetheless.
Too bad you didn't produce that about 20 posts ago

With Respect,
Matt
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Sorry, wasn't posting then :-)
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Hi Matt, Hi All
I've not been around a couple of days.
I am happy that you did solve the problem using JDK 1.3.1
About InetAddress.getLocalHost() that returns the loopback address : this problem is easily solved by modifying the /etc/hosts file the way discribed above in this topic. (and if you haven't modified the /etc/hosts file you would still encounter the following problem : cannot connect to 127.0.0.1 even with JDK 1.3.1)
Now I am quite sure that with JDK 1.4 InetAddress.getLocalHost() returns 0.0.0.0 independently of the content of /etc/hosts file!!! (a bug maybe)
Once again, congratulations.
Regards
[ July 03, 2002: Message edited by: Omar IRAQI ]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Always nice to have a happy ending.
You guys have been busy! I just wanted to clarify something though. Omar is correct that no tcp/ip port is inherently dangerous. I used the word in quotes for that reason.
However, to reduce the exploitability of an installation, many organizations will firewall off inbound requests to all except the most essential services. In many cases, this means nothing comes in but email, http, and ftp. And in extreme cases, maybe nothing but http. I've known a number of banks that did that. Which locks you out of the RMI connection on 1099. I don't advise BTW to put RMI on port 80, since RMI can't serve up http requests.
"Dangerous" is obviously a relative term, of course. Consider what Code Red can do using the "safe" port 80.
YIJI LIN
Greenhorn

Joined: Apr 17, 2004
Posts: 1
"About InetAddress.getLocalHost() that returns the loopback address : this problem is easily solved by modifying the /etc/hosts file the way discribed above in this topic. (and if you haven't modified the /etc/hosts file you would still encounter the following problem : cannot connect to 127.0.0.1 even with JDK 1.3.1)"
It is a great help for me. I have already worked for a problem for a RMI project in linux for two weeks until I have this message. How happy I am!
Chris Shepherd
Ranch Hand

Joined: Jun 27, 2000
Posts: 286
This is why people should always search the old posts for answers to their questions first. (Two year gap between posts optional)

Glad you found what you needed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI problem on Linux