river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Fix for RIVER-17 and RIVER-18
Date Thu, 31 Jan 2008 06:10:13 GMT
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


> 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.
-- 
Mark

Mime
View raw message