Bug 29501 - RMI fixed to localhost?
Summary: RMI fixed to localhost?
Status: UNCONFIRMED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.91
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-18 15:47 UTC by das05
Modified: 2010-09-16 15:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Remote interface A (108 bytes, text/plain)
2006-10-18 15:48 UTC, das05
Details
Remote interface B (118 bytes, text/plain)
2006-10-18 15:49 UTC, das05
Details
Class A (281 bytes, text/plain)
2006-10-18 15:49 UTC, das05
Details
Class B (261 bytes, text/plain)
2006-10-18 15:50 UTC, das05
Details
Modification of gnu.java.rmi.server.UnicastConnectionManager (4.37 KB, text/plain)
2006-10-30 11:29 UTC, das05
Details
blue sky with flowers (26.05 KB, patch)
2009-08-14 16:24 UTC, Jessie
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description das05 2006-10-18 15:47:48 UTC
When I attempt to call a Remote object which is running on JamVM with Classpath, the calls fail because the caller (which is running Sun's JVM and libraries) attempts to access localhost rather than the machine the Remote object is on.

When the same Remote object is running on another machine which is running Sun's JVM+libraries, no such problem occurs.

In the example code I will attach, class A (implements RemoteA) is running on JamVM+Classpath and class B (implements RemoteB) is running on Sun's JVM, on a machine with rmiregistry. Class A looks up class B and is supposed to call class B to register itself, and then class B can call A.hi().

The A.hi() call results in a ConnectException with message "connection refused to localhost".

Interestingly, the reverse problem does not occur - code running on Classpath can call a Remote object on Sun's libraries.

Furthermore, if the rmiregistry is run on the machine with Classpath, the very same exception occurs. It's as if there is a field in the object passed out from the Classpath machine that contains the IP calls should go to, and this is fixed to localhost.

I have also been using the -D...codebase= and -D...policy= options as necessary, and I have even tried -Djava.rmi.server.hostname=thecorrectone and adding the correct host to /etc/hosts. None of these attempts work.
Comment 1 das05 2006-10-18 15:48:56 UTC
Created attachment 12452 [details]
Remote interface A
Comment 2 das05 2006-10-18 15:49:19 UTC
Created attachment 12453 [details]
Remote interface B
Comment 3 das05 2006-10-18 15:49:35 UTC
Created attachment 12454 [details]
Class A
Comment 4 das05 2006-10-18 15:50:06 UTC
Created attachment 12455 [details]
Class B
Comment 5 das05 2006-10-30 11:29:42 UTC
Created attachment 12511 [details]
Modification of gnu.java.rmi.server.UnicastConnectionManager

Altered lines 184/185 to use the java.rmi.server.hostname property rather than default to localhost when working as a server. I have no idea whether this is 'correct', but it has the nice property of solving the problem I've described.
Comment 6 Jessie 2009-08-14 16:24:28 UTC
Created attachment 18363 [details]
blue sky with flowers

Interrupt service routine
Comment 7 Matt 2010-09-16 15:16:36 UTC
I have this same problem.  The hack of Comment #5 fixes it for me, but is would be nice not to have to do this on every system we deploy.