On Fri, 2012-10-12 at 07:05, Simon IJskes - QCG wrote: > Wouldn't the server socket in LookupDiscovery.ResponseListener be a good > candidate to be made configurable? It is now > > serv = new ServerSocket(0); > > that means, on a fixed firewalled host, this will not work. The thread > is started only once the documentation states, so if it is fixed by > configuration, no problems should occur in a single instance. >
I just had a quick look at the code for LookupDiscovery. Hard to tell without going deeper, but it looks like it sends multicast requests on a set of network interfaces configured by the 'multicastInterfaces' config entry, and includes a host name configured by the 'multicastRequestHost' configuration entry. The ServerSocket listed above will listen for responses to the multicast (which are unicast) on all the network interfaces. So I don't think the 'new ServerSocket(0)' is wrong. It might be slightly more correct to create a listener for each interface, but I suspect the ServerSocket(0) is a reasonable hack. So, I think that LookupDiscovery is already configurable enough. Similarly, the real solution for any other uses of 'InetAddress.getLocalHost()' in the codebase is to make the component properly configurable with a host name. Now, as for your thought on a configurable strategy for figuring out the preferred local hostname, there's already a utility class called 'com.sun.jini.config.ConfigUtil' that has methods for 'getHostName()' and 'getHostAddress()'. Currently they just call 'InetAddress.getLocalHost()'. Perhaps we could add a pluggable strategy there. Probably just have another version of the methods take a strategy object. That way it would be usable from inside a Configuration object. Oh, and I'd assume that we would rename the utility class to 'org.apache.river.config.ConfigUtil'. Thoughts? Greg. > Gr. Simon > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
