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]
