river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vinod Johnson <Thomas.John...@Sun.COM>
Subject Re: Fix for RIVER-17 and RIVER-18
Date Thu, 31 Jan 2008 14:45:31 GMT
Mark Brouwer wrote:
> Hi Vinod,
> Thomas Vinod Johnson wrote:
>> Mark Brouwer wrote:
>>> Hi all,
>>> Attached the patch for RIVER-17 and RIVER-18, I'm sorry for the 
>>> grouping
>>> but due to historical reasons this is the easiest way with the smallest
>>> risk of failure to create the patch for me.
>> For RIVER-18, I don't recall the discussions surrounding it, and the 
>> pointer in the report appears to point to nowhere. The change does 
>> not seem problematic to me, but I want to make sure I understand the 
>> motivations.
> Strange, have a look at 
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200703.mbox/browser 
> and you will find many missing mails and also subject lines that are 
> not a link. I'm sure that when entering the link in JIRA there was an 
> archived message. I don't like the archives we have, but I hope that 
> this is something that can be fixed ...
> Original posting:
> "While performing some tests for secure discovery I noticed that unicast
> discovery started to fail on Java SE 6 while it worked for J2SE 1.4.2
> and J2SE 5.0.
> To make a very long story of troubleshooting very short it turned out
> that due to the way the discovery related classes deal with the order in
> which they use the unicast discovery providers the behavior can differ
> between JVM. One can argue whether this is a problem or not, but at
> least it is *very* confusing, it did cost me a lot of time (in which I
> gained a lot of knowledge, so it wasn't completely waisted) and in this
> case it turned out that while unicast discovery could have happened, it
> didn't (which I think is bad).
> The constraints effective [1] for the test were so that both the
> plain-text and ssl providers were selected, however on J2SE 1.4.2 and
> 5.0 was the order { plaintext, ssl } and for Java SE 6 { ssl, kerberos
> }. I tested with the Sun JVM on Windows and Solaris x86.
> I could track down the problem to DiscoveryV2.doUnicastDiscovery where
> an HashSet is used for the local variable 'fids' to store the discovery
> formats that match the constraints effective. Changing the HashSet into
> LinkedHashSet resulted in a predictable iteration order and the behavior
> is now consistent for all versions of Java.
> However this shows to me a bigger problem and that is which discovery
> provider to use as preference. The small change from HashSet to
> LinkedHashSet provides predictability but doesn't help much in which
> provider to select first. That order seems to be determined mainly by
> the way the service providers at the client side are found through
> com.sun.jini.resource.Service, which boils down to the semantics for a
> TreeSet.
> My question is whether there is a strong rationale behind the TreeSet,
> because my gut feeling would say that a LinkedHashSet would have been
> better here to, this way the order in which the discovery providers are
> stored in the
> META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file(s)
> would have been leading. In which case I could have put PlainText on the
> first spot as that one is likely to work under all conditions.
> [1] the constraints required client and server authentication to be NO,
> and that means that anonymous SSL could have worked, hence the selection
> of the SSL provider. But the lookup server was not able to support
> anonymous SSL because a server principal was selected due to what I
> would call limitations in the ability to configure some parts of the
> server side unicast discovery part but that I'll post in a different 
> mail.
> [2] for multicast discovery all providers that pass the constraints
> checks are used to send multicast requests or announcements. With
> unicast discovery you can only get one shot as a client, i.e. even while
> you might have multiple unicast discovery providers it is up to the
> lookup server to decide which one it will use and it is proven it can
> make a bad decision. My question is why doesn't the unicast discovery
> response for version 2 contain alternative format IDs, besides the one
> chosen by the lookup server. This would have given the client the
> ability to try out other unicast discovery requests with a single format
> ID in case the one chose by the server fails."
> Bob's response is here 
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200703.mbox/%3c46097E02.70800@Sun.COM%3e

Thanks for digging it up.
>> Also you appear to have added some extra logging not covered by 17 or 
>> 18, though that's fine by me.
> Additional logging is likely part of RIVER-20, but the ones that might 
> cause some discussion are not in this class.
> I hope this explains things a bit, thanks for looking into the patch 
> Vinod.
Yes it's all coming back to me in bits and pieces :) I have no issues 
with your changes.

View raw message