river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: RIVER-325: Use of socket factory in LookupLocator
Date Wed, 11 Nov 2009 20:27:13 GMT
Wow, I had not chased through all this code.  I had assumed that 
LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in fact it 
does not, and recreates all the processing itself and uses introspection to 
reference the getRegistrarMethod for constraints, but otherwise does not call it.

Anyone from Sun have any comments on why getRegistrar() is not used by 
LookupLocatorDiscovery?

Gregg Wonderly

Sim IJskes - QCG wrote:
> Gregg Wonderly wrote:
>> Are there any other issues that we need to deal with in adding a new 
>> constructor?  I am wondering about "net.jini.discovery.timeout" as a 
>> system property.  Do we want to provide the ability to pass this into 
>> the constructor too?  I have cases where I want this to be short for 
>> some locators and long for others, but have to go with the global 
>> setting because of this implementation detail.
> 
> The LookupLocator is (in part) a value object. Its role, one of them, is 
> pointing to the place where we can find a Registry. I did a scan of the 
> sources, and i cannot find a place where another jini class actually 
> retrieves the registry from the LookupLocator.
> 
> So any implementation that retrieves the ServiceRegistrar can set the 
> individual timeout for the lookup with:
> 
> public ServiceRegistrar getRegistrar(int timeout)
> 
> I can foresee situations where this method isn't very helpfull to solve 
> the problem of per-locator timeouts.
> 
> Gr. Sim
> 


Mime
View raw message