net.jini.lookup.JoinManager
is a utility class that, along with supporting interfaces and classes,
encapsulates functionality that can help Jini technology-enabled services
(Jini services) demonstrate good behavior in their discovery-
and registration-related interactions with Jini lookup services.
In particular, this utility performs functions related to lookup
service discovery and registration (joining), as well as lease
renewal and attribute management.
The specification for the
JoinManager
utility (join manager) is contained in the Jini Join Utilities Specification,
which is available in html.
This new entry allows one to configure the maximum lease duration (in milliseconds) that is requested from each discovered lookup service on behalf of the service; both when the lease is initially requested, as well as when renewal of that lease is requested. Thus, as this value is made smaller, renewal requests will be made more frequently while the service is up, and lease expiration will occur sooner when the service goes down.
This new configuration entry is a result of RFE 6202650,
described below.
A full list of supported configuration entries is given in this utility's class documentation.
Logger
named net.jini.lookup.JoinManager. For a description of the
information that is logged, as well as the associated logging levels, refer to the
class documentation.
public void replaceRegistration(Object serviceProxy) {...}
public void replaceRegistration(Object serviceProxy, Entry[] attrSets) {...}All necessary modifications were made to the join manager implementation to comply with this change.
All necessary modifications were made to the join manager implementation to comply with this change.
After registering the service with a lookup service, the
join manager passes the resulting lease to the lease
renewal manager, requesting that the lease be renewed at regular
intervals based on the lease duration ultimately granted by the
lookup service. This means that when the service goes down and
the lease renewal manager is no longer available to renew the
service's lease, the lookup service will not notify interested
parties that the service is down until that lease duration has
actually passed. Thus, the timeliness of such notifications is
directly related to the maximum lease duration granted by the
particular lookup service implementation with which the service
was registered. If the developer of a system desires more timely
notification of a service's demise, the developer either has to
configure/administer the lookup service to grant shorter leases,
or subclass the lease renewal manager supplied to the
join manager.
Although the lease renewal manager provides the ability for the
user of the lease renewal manager to control the lease duration
requested, and thus the length of the renewal interval, until
now, the join manager did not provide the service
with access to this functionality. Over the years, a number of
users have asked for this capability. This feature enhancement
is intended to satisfy that request.
All necessary modifications were made to the join manager
implementation to comply with this change.
This bug has been fixed.
This bug has been fixed.
This bug has been fixed.
This bug has been fixed.
Because discard lookup service --> DiscMgrListener.discarded()
removeTasks
queue DiscardProxyTask
re-discover lookup service --> DiscMgrListener.discovered()
if(!joinSet.contains(lookup service)) --> add lookup service to joinSet
--> queue RegisterTask
DiscardProxyTask runs
remove lookup service from joinSet
cancel service's lease with the discarded lookup serviceDiscMgrListener.discovered() tests joinSet for
the lookup service before DiscardProxyTask removes that lookup
service from joinSet (and cancels the service's lease with
the lookup service), the RegisterTask is not queued and run; thus, the service is never re-registered with the lookup service.
DiscoveryManagement
item (entry name = discoveryManager), a default
LookupDiscoveryManager
is first created. Although that manager is initialized to discover no groups and no locators,
the LookupDiscovery
instance used by the default discovery manager to perform group discovery creates
a thread to listen for and process multicast announcements, as well as
additional, related threads. Thus, if a deployer configures a discoveryManagement
item, the creation of the default lookup discovery manager -- and the threads
that manager ultimately creates -- is unnecessary, and wastes resources.
UnknownLeaseException
followed by a re-registration can repeatedly occur. This condition is
intitiated by a discard of the lookup service coincident with a service
lease expiration.