It's been a little while since I spent time pouring over the discovery code.
We need to focus on discovery v2, which extends LookupDiscovery. From memory the code in LookupDiscovery is disco v1. Cheers, Peter. ----- Original message ----- > > 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 >
