Re: Connection Refused Exceptions

Gregg Wonderly wrote:
> Rick Moynihan wrote:
>> I'm using RMI to communicate between the proxy and the service, and I
>> suspect the problem is that the proxy's RMI stub to the
>> UnicastRemoteObject is stale because of the restart.  However, upon
>> restart my services all register back with the lookup service through
>> the JoinManager.   Though my knowledge of RMI is sketchy, I would have
>> thought that this process would ensure that a new proxy/stub was
>> registered on the lookup service.
>>
>>
>> Does anyone have any ideas on what might be causing the problem?  Any
>> help would be highly appreciated.
>
> The registration of services is primarily driven by unique ServiceID
> values. If
> your reregistration is not with the same ServiceID, then your
> registration will
> be added to the set of registered services, and not replace a particular
> registration.  Lease expiration will eventually cause registrations to be
> removed from the registrars content so that you won't see these "dead"
> entries.

I'm using the JoinManager and cover both of the cases you describe.  I
use a ServiceIDRecorder for registering the first service registration
or if I have one persisted to disk, I will use that instead.  To do this
I use the two constructors like so:

if(serviceIdSet) {
     joinManager = new
JoinManager(serviceProxy,entries,serviceID,discoveryManagement,leaseRenewalManager);
} else {
     joinManager = new JoinManager(serviceProxy,entries,new
ServiceIdRecorder(),discoveryManagement,leaseRenewalManager);
         }

> So, if you don't have a registered shutdown hook in the services' VMs
> that will
> be able to successfully shutdown your join manager, or if the service dies
> unexpectedly in a way that keeps the shutdown hook from running, then the
> service registration will remain until the lease expires, or it is
> replaced with
> a new registration for a service with the same serviceID.

Thanks for reminding me about the shutdown hook as I do need to
implement this.  However doing so just now would only work around the
issue in the common case (the user killing the service).  In a real
error scenario this wont occur (e.g. powercut), yet the service may
restart prior to the expiration of its lease.  It is this scenario which
often generates a ConnectException.

> There are also facilities in JERIs endpoint configuration to used
> preassigned
> ports for the endpoints and preassigned object identifiers in the
> exporter so
> that a particular service will always be exported with the same object
> identifier at the invocation layer, and associated with an endpoint that is
> always on the same port.
 >
 > If you use that facility, then stale registration info becomes less of
 > an issue,
 > and if the service is running, clients should be able to use it.

Unfortunately we're still using Jini 1.2.1_001 (no JERI), and have been
for years.  Without too many problems.  I'm not entirely sure on how
much work it would be to upgrade to Jini 2.0.  I'm guessing it would be
fairly trivial as the API's are largely unchanged.  I'd certainly like
to upgrade in the future, but for now I don't think it's worth it as
it'll involve changing a lot of deployment/build scripts etc.  Though
I'd be interested to know what it would involve beyond that.

Is there anything else that might be causing this problem?

--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/

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