Hi,
Sorry, my description of the problem was misleading and missed the most
important point, so:
Disabling IPv6 on the server did not actually fix the problem - the
getLocalHost() method would still return 127.0.0.1 on some (e.g. Fedora
and Red Hat) servers. The problem disappeared only after we changed the
original JAR to one which uses a version of the getLocalHost() similar
to the one below.
Running the simple test:
public class Test{
public static InetAddress getLocalHostLANAddress() throws
UnknownHostException {
try {
for(Enumeration ifaces =
NetworkInterface.getNetworkInterfaces(); ifaces.hasMoreElements();){
NetworkInterface iface =
(NetworkInterface)ifaces.nextElement();
for(Enumeration inetAddrs = iface.getInetAddresses();
inetAddrs.hasMoreElements();){
InetAddress inetAddr =
(InetAddress)inetAddrs.nextElement();
if (!inetAddr.isLoopbackAddress() &&
inetAddr.isSiteLocalAddress()) {
return
InetAddress.getByAddress(InetAddress.getLocalHost().getHostName(),
inetAddr.getAddress());
}
}
}
}
catch (Exception e) {
throw new UnknownHostException("Failed to determine LAN
address: " + e);
}
throw new UnknownHostException("Failed to locate LAN address.");
}
public static void main(String[] args){
try {
System.out.println("fixed -
getLocalHostLANAddress(): "+getLocalHostLANAddress());
System.out.println("InetAddress.getLocalHost()"+InetAddress.getLocalHost
());
System.out.println("InetAddress.getLocalHost().getHostAddress()"+InetAdd
ress.getLocalHost().getHostAddress());
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
}
produced the output on Windows:
fixed - getLocalHostLANAddress(): <hostName1>/192.168.x.y
InetAddress.getLocalHost()<hostName1>/192.168.x.y
InetAddress.getLocalHost().getHostAddress()192.168.x.y
but the output on Linux was:
fixed - getLocalHostLANAddress(): <hostName2>/192.168.a.b
InetAddress.getLocalHost()<hostName2>/127.0.0.1
InetAddress.getLocalHost().getHostAddress()127.0.0.1
The fact that this differs suggests that getLocalHost() cannot be used
reliably in the way that the current version of JCS uses it.
The test case just uses a simple algorithm: the getLocalHostLANAddress()
method iterates through all IP addresses held by the server, and selects
the first non-loopback, site-local (192.168.x.x) address. (This method
would not account for servers which do not have a site-local address
e.g. (in the rare case) where the server's only non-loopback IP address
is a public internet address. )
It would be nice if a similar - and perhaps more effective - solution
was built into JCS with an algorithm which can handle most networking
configurations.
Thanks,
Zsolt
-----Original Message-----
From: Zsolt Varszegi [mailto:[EMAIL PROTECTED]
Sent: 23 March 2007 16:07
To: JCS Users List
Subject: RE: IPv6 problem on Linux
Hi Al,
as much as I remember I have not tried this - I only tried to work with
IP addresses.
(I think I should have written to the list a bit earlier because by now
- after disabling IPv6 support on our server altogether - the problem
disappeared. I just mentioned it so that developers are aware.)
Thanks anyway,
Zsolt
-----Original Message-----
From: Al Forbes [mailto:[EMAIL PROTECTED]
Sent: 21 March 2007 16:11
To: JCS Users List
Subject: Re: IPv6 problem on Linux
Hi Zsolt,
Have you tried using changing the rmi property with something like:
-Djava.rmi.server.useLocalHostname=true
Regards
Al
On 20/03/07, Zsolt Varszegi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was trying to set up a distributed cache architecture with JCS, the
> memory cache and the disk auxiliary were working just fine but I could
> not set up the remote auxiliary properly.
>
> After some investigation I suspect that the reason the client could
> not communicate with the server properly has to do with the JCS code
> relying on InetAddress.getLocalHost() method call which returns
> ambiguous results on Linux systems. (I later found a bug report about
> this at
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665037 ).
>
> E.g.: client looking up an IPv6 enabled Fedora Core 6 server:
>
> "looking up server
> //192.168.6.28:1102/org.apache.jcs.auxiliary.remote.behavior.IRemoteCa
> ch
> eService"
> org.apache.jcs.auxiliary.remote.RemoteCacheManager 107:Naming.lookup(
> "//192.168.6.28:1102/org.apache.jcs.auxiliary.remote.behavior.IRemoteC
> ac
> heService" );
> "server found"
> "remote service = RemoteCacheServer_Stub ...
> endpoint:[0:0:0:0:0:0:0:1:1103](remote),objID:[7c19e... etc."
>
>
> at the same time the same client looking up another also IPv6 enabled
> Fedora Core 6 server:
>
> "looking up server
> //192.168.10.59:1102/org.apache.jcs.auxiliary.remote.behavior.IRemoteC
> ac
> heService"
> org.apache.jcs.auxiliary.remote.RemoteCacheManager 107:Naming.lookup(
> "//192.168.10.59:1102/org.apache.jcs.auxiliary.remote.behavior.IRemote
> Ca
> cheService" );
> "server found"
> "remote service = RemoteCacheServer_Stub ...
> endpoint:[192:168.10.59:1103](remote),objID:[806c6c..."
>
>
> A possible workaround could be to replace the
> InetAddress.getLocalHost() calls with a method similar to the snippet
> below to return the IP address that enables RMI calls from remote
> machines:
>
>
> public static String getLocalHostAddress() throws
UnknownHostException{
> return getLocalHostLANAddress().toString();
> }
>
>
> public static InetAddress getLocalHostLANAddress() throws
> UnknownHostException { try {
> for(Enumeration ifaces = NetworkInterface.getNetworkInterfaces();
> ifaces.hasMoreElements();){
> NetworkInterface iface = (NetworkInterface)ifaces.nextElement();
> for(Enumeration inetAddrs = iface.getInetAddresses();
> inetAddrs.hasMoreElements();){
> InetAddress inetAddr = (InetAddress)inetAddrs.nextElement();
> if (!inetAddr.isLoopbackAddress() &&
> inetAddr.isSiteLocalAddress()) {
> return
> InetAddress.getByAddress(InetAddress.getLocalHost().getHostName(),
> inetAddr.getAddress());
> }
> }
> }
> }
> catch (Exception e) {
> throw new UnknownHostException("Failed to determine LAN address: " +
> e); } throw new UnknownHostException("Failed to locate LAN
> address."); }
>
>
> I could bypass the problem by completely disabling IPv6 on our server
> but for the future it might be beneficial to ensure JCS runs reliably
> on Linux without a need to make such configuration.
>
> If you think there are other ways to sort out this issue please let me
> know.
>
> Regards:
> Zsolt
>
> P.S.: Good luck with JCS - a very nice piece of work otherwise.
>
---------------------------------------------------------------------
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]
