Re: Dynamic proxy preparers

Mark Brouwer wrote:

> 1) LookupLocatorDiscovery
>
> Failure during lookup service proxy preparation results in endless
> retries with a maximum interval of 15 minutes. Meaning a modified proxy
> preparer might result in a lookup service becoming 'visible' with a
> maximum delay of 15 minutes.
>
> A hook into LookupLocatorDiscovery to execute all outstanding retry
> tasks could speed up the process.

Another issue I found out about with LookupLocatorDiscovery is the fact
many decisions in the utility are based on LookupLocator.equals and
given the fact ConstrainableLookuplocator doesn't override equals that
means undiscovered lookup servers (due to constraints) won't be able to
get discovered if you pass in a new set of lookup locators with only
different constraints attached (that might make discovery possible). The
retries will continue to be executed with the locators with the old
constraints, if any. I'll file an issue against River.

Maybe it is nice to think of this when thinking about
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6211447. Also I think
it might be necessary to reconsider lookup locator equality [1] if we
decide to have a go at unicast discovery over HTTP as part of River.

[1] my hunch at this moment is that lookup locator should be completely
URI based and that equality should be defined as in URI equality.
Multiple lookup locators can result in a single lookup service, as the
bug report states there seems to be an assumption that the host/port
combination uniquely defines a lookup service and I think that is not
the right way forward. This assumption already gave me problems when
doing the work for Jini across the Firewall.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]