Re: Recommendations for working with LookupCache

It sounds like you are simulating failure cases. If you gracefully
shut-down a service and are correctly cleaning things up, it should
de-register from all of its LUS correctly and clients should be
notifiable at a reasonable time period.

However, in failure cases, I find it best to do lookups in a
configurable loop. You do a lookup and if  that service fails, throw it
out (you can also tell the LookupCache to toss it as well) and try
again. I think we found that 3 lookups was usually more than enough to
find a usable service.

One method for accomplishing this that I've used is dynamic proxies. You
create a factory to lookup services and that creates a dynamic proxy.
The dynamic proxy does the lookups and then invokes the interface method
on the service if finds. This can be done in the InvocationHandler for
the dynamic proxy.

-bp


Patrick Wright wrote:
> Hi
>
> We've been exploring Jini for about six months. This email is to
> gather feedback on what pattern is recommended for handling lookup on
> services that may disappear or reappear over time.
>
> The case is that we have a client (web server) which performs a lookup
> for a given service using a ServiceDiscoveryManager and a LookupCache.
> The Jini configuration in this case is very simple: there is one group
> we associate services with, and currently only one service we are
> trying to bring online in this server setup. The service is accessed
> via a thin (remoting) proxy. There are usually two LUS instances, one
> central one, and one launched in the same process as the service
> itself, as a backup. Both LUS are associated only with the same,
> single group.
>
> On the client side, lookup is performed in a sort of factory class,
> that is, all threads in the webserver use the same lookup factory
> instance. The lookup factory initializes the SDM and lookup cache on
> startup, and uses these throughout its lifespan.
>
> The situation arose where the service instance was brought down, and
> then restarted. The service did not attempt to cancel its own lease,
> and thus service-instance-1 remained in the LUS until its lease
> expired. The service registration is configured such that a new,
> unique service id is granted by the LUS, that is, service ids are not
> reused. In a simple test setup I created to understand the behavior,
> the lookup cache retained the reference both to service-instance-1
> (I-1) and service-instance-2 (I-2) even if the discard(service) method
> was called on the cache. This is problematic, since without any
> additional checks it is possible that either I-1 or I-2 would then be
> returned from the lookup factory, even if I-1 was no longer available
> (referred to a non-existing service instance).
>
> It is OK if the service is temporarily unavailable; the client
> processes can handle that gracefully. However, if a new instance of
> the service is available, we would like to use that, and no longer try
> to access the service using the old registration.
>
> I can't find any way to do this using the standard Jini classes
> themselves. My current approach, which appears to work in a simple
> test, is that, if a service call fails with a remote exception, the
> lookup factory is notified, and the factory stores the reference to
> the service (by service id) in a WeakHashMap. The LookupCache is then
> configured with a ServiceItemFilter that checks the map in the
> check(ServiceItem) method. If the service discovered in the cache is
> in the map, it is skipped.
>
> At some point, the lease on the service will expire from the LUS, the
> cache will receive a service-removed event, and there won't be any
> more invalid references. The entries in the invalid-service-item map
> will be garbage collected, possibly before the lease expires, or
> possibly after. There's thus the chance that the entry in the map
> could be GC'd before the lease expires, causing another failed call to
> the service, but the setup seems simpler to code and test than, say, a
> List with a cleanup thread and timeout period.
>
> I appreciate any feedback on this approach or suggestions for
> alternatives. FWIW, I haven't been able to find any documentation on
> actual recommended practices or patterns for handling unreliability in
> distributed services, just a lot of warnings about unreliability :).
> I'm interested in this case in recommended, best practices.
>
> Thanks
> Patrick
>
> --------------------------------------------------------------------------
> 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]
>


--------------------------------------------------------------------------
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]