Re: reggie started?

Rikard Elofsson wrote:
> Mark Brouwer skrev:
>> You probably feel it coming ... ... can you post the complete stacktrace?
>
> Pasted below

Thanks Rikard as it answer a few questions.

>> But when it is the connection refused exception means there is no
>> process listing on the host/port combination you are trying to connect
>> to due to unicast discovery I don't understand why you want to get rid
>> of it in the first place. Can you also indicate what is doing the
>> unicast lookup, is it the SDM or you from a Jini Service Browser.
>
> code like this:
>
> Class[] classes = new Class[] { type };
> ServiceTemplate template = new ServiceTemplate(null, classes, null);
>
> DiscoveryManagement discover;
>
> LookupLocator[] locators = new LookupLocator[] { new
> LookupLocator("jini://localhost") };
>
> discover = new LookupLocatorDiscovery(locators);
>
> ServiceDiscoveryManager clientMgr = new
> ServiceDiscoveryManager(discover, new LeaseRenewalManager());
>
> clientMgr.createLookupCache(template, null, this);

Ok, the designer(s) of LookupLocatorDiscovery decided when a unicast
lookup fails it should report some cases at the INFO level and while you
can have endless debate about whether this should be INFO level or
HANDLED. I think it is OK to report this failure at INFO [1] level as it
is you who expects a lookup server to be there given the explicit
crafting of the Jini URL.

Apparently your Reggie is not up and running yet when the above code is
executed so one or more of these exceptions (LookupLocatorDiscovery
backs off after each failure and doubles the retry time till it reaches
some limit) will be displayed. As you said after a while it works and
that is due to the retries performed by LookupLocatorDiscovery and
therefore I wouldn't worry about it. I'm not saying the logging for
LookupLocatorDiscovery can't be improved by e.g. logging only the first
failure at INFO level, the subsequent failures with the same cause at
HANDLED level and when a retry succeeds to log that fact at INFO level
again. If that is what you want or something different feel free to file
an issue against River.

If you really want to (in most cases) get rid of the exception you could
introduce a delay between starting your LUS and the code above. Even
better is to have a LUS running that is always available, not only does
it prevent you from getting this exception, it will also force you to
work around/against 'debris' found through the lookup service. With
debris I mean left overs from services that crashed or taken from the
network for which the lease with the lookup server wasn't canceled and
that can be found with the next trial of your Jini application but that
likely won't work.

[1] I can remember case where I had to mask INFO level messages due to
'customer fear' of stacktraces in log files but if that is not the case
I wouldn't worry about it.

> -----------------------------------------------------------------------
> stack trace below...
> -----------------------------------------------------------------------
>
> INFO net.jini.discovery.LookupLocatorDiscovery$LocatorReg exception
> occured during unicast discovery
>  to {0}:{1,number,#} with constraints {2}
>

Are you using Log4J? The substitution doesn't seem to work properly. I
encountered something similar once for a Resin webapplication server and
the person enabled J2SE logging through Commons Logging and gone were
the problems.
--
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]