river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Johnson - Sun Microsystems <Thomas.John...@Sun.COM>
Subject Re: Integrity.NO constraint results in selection of X500Provider instances
Date Wed, 28 Mar 2007 13:42:09 GMT
Mark Brouwer wrote:
> Vinod Johnson - Sun Microsystems wrote:
>
>> This may just be a logging bug. If you happen to be invoking 
>> DiscvoeryV2.decodeMulticastAnnouncement with delayConstraintCheck set 
>> to true, this enables you to delay constraint checking until a more 
>> opportune time. This feature is currently used in LookupDiscovery 
>> (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4867820 for 
>> more information on this). It looks like when this feature was added, 
>> the logging message was not updated to reflect the fact that 
>> constraint checking has been delayed.
>>
>> If you happen to be using LookupDiscovery, you should see a later 
>> logging message from LookupDiscovery (at HANDLED level) - "exception 
>> decoding multicast announcement", with the associated exception. This 
>> is the point at which the constraint check is actually done.
>
> Hi Vinod,
>
> You are probably right. I went through the log files and I found *no*
> HANDLED messages that indicated a failure, but that turned out to be
> logical as I only enabled logging for com.sun.jini.discovery. I didn't
> configure the loggers for LookupDiscovery. It might be helpful to log
Also, the constraint check is only done if LookupDiscovery decides that 
the announcement is of interest (like the LUS has not been seen so far 
or the groups have changed)
> these kind of failures also at the FAILED level for the Discovery
> implementations, that way we have a central point for all discovery
> related 'logging' which seems to me more helpful than tracing the
> entities calling the various Discovery methods, what do you think?
>
Seems like a value add, but I don't know if there is any consistent 
theory in the code around logging all failures before an exception is 
thrown.
> BTW you filed an issue for the 'confusing logging' and assigned it to
> yourself, given the fair number of improvements (context information) I
> already made in the discovery related code do you mind if I assign that
> issue to myself to prevent from extra work to resolve your code and mine
> code in the future.
>
> In case the full constraints verification is delayed the log message 
> will be appended with ", full constraints checking has been delayed" 
> but if you now a better description for what is actually happening 
> please let me know.
Thats fine.

-- 
- vinod

Mime
View raw message