Re: Dynamic proxy preparers

Bob Scheifler wrote:
>> Are within the JTSK classes that take ProxyPreparer instances
>> assumptions the process followed during proxy preparation is constant
>> (e.g. failures due to constraints seen as definite).
>
> I'm not sure if this helps, but a principle we tried to adhere to is that,
> within a component, a given proxy is only prepared once.  I believe that
> included not retrying after an exception.

It seemed I had to do the code inspection as your answer was not what I
had hoped for (but that is not your fault). The preliminary results are
below, just for those who find this interesting and for those who can
provide some feedback (especially when my interpretation went wrong).


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.


2) LookupDiscovery

Failure during lookup service proxy preparation results in the proxy
being ignored, but in case a lookup service keeps advertising itself,
upon the next advertisement it will be verified. Therefore a modified
proxy preparer might result in a lookup service becoming visible after
it has advertised itself.

LookupDiscovery doesn't allow for changing discovery constraints, this
feature is something you likely want to have available in time when you
support dynamic proxy preparers. I don't know whether it sound very
naive but to me it doesn't seem very difficult to reinitialize the
discovery process when you accept that lookup services once discovered
are OK and shouldn't comply with the new constraints.


3) JoinManager

Failure during lookup service proxy preparation results in the lookup
service being discarded, meaning it is eligible for rediscovery. Failure
during registration or operations on the registration due to a
non-indefinite exception results in the lookup service being discarded,
meaning it is eligible for rediscovery.

Therefore modifying proxy preparers for the purpose of join management
will have effect after the delays caused by LookupDiscovery and
LookupLocatorDiscovery.


4) ServiceDiscoveryManager

Failure during lookup service proxy preparation results in the lookup
service being discarded, meaning it is eligible for rediscovery. Failure
to prepare the lease associated with the event registration will also
discard the lookup service, making it eligible for rediscovery.

Therefore modifying proxy preparers for the purpose of finding lookup
servoce will have effect after the delays caused by LookupDiscovery and
LookupLocatorDiscovery.

With the ServiceItemFilters passed in to any of the LookupCache methods
there is no problem at all as these will be executed against the content
of the cache and as such have no impact on the content only on the
outcome of that method invocation. The same for the ServiceItemFilter
used for the lookup methods on ServiceDiscoveryItem that take no
time-out argument.

The difficulties arise with the ServiceItemFilter passed in with the
createLookupCache method as this filter is used when populating the
cache. When proxy preparation fails in a way that can be considered
definite for the given proxy preparer the service item is not placed in
the cache and the service item can only become visible when the lookup
service indicates the service item has been changed.

A solution to this would be to mimic an indefinite failure as it has
the effect the service is discarded, making it eligable to rediscovery.
Digging through the code I see the following problems with this approach
(I can be easily wrong here, although well documented the code is a
piece of rocket science):

Problems I see are:

  - retry is not indefinite, only one retry takes place in case failure
    is due to an indefinite failure during filtering
  - failure during filtering might lead to a large number of discard
    tasks and each discard task will consume one thread up to 10 minutes
    (assuming the task manager is allowed to create an unlimited number
    of threads). IMHO this is something I would have preferred a more
    resource efficient solution for.

Therefore modifying proxy preparers for the purpose of service discovery
might be better implemented through some hook that would signal the
lookup cache it should snapshot the lookup services found and compare
the new snapshot with the current state and follow the process currently
followed with the exception that service items found and considered
equal are not prepared for a second time. This would be the same
strategy as followed when an event gap is detected while receiving
discovery events. My expectation is that modifying proxy preparers is
not something that happens every 5 minutes so the snapshot doesn't seem
that bad and all code is already in place.


Sort of conclusions
-------------------

The Jini utilities have a great ability to adapt to changing
circumstances with regard to services out there on the network. It might
take some time before they become aware of the changed circumstances,
but in time they do.

I think a software system should be able to cope with changing trust
relationships as well or other configuration aspects. We acknowledge the
fact additional untrusted servers can come and go, I think we should be
able to deal with additional trusted services that come and go too.

Maybe it is time for adding a ninth fallacy of distributed computing:
"Trust relationships don't change" ;-).

I believe the hooks can be implemented without touching the public API
of the utilities as we have a Configuration object that can be utilized
to get them in. In case I overlooked something or I'm on the wrong track
please let me know.
--
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]