Order in which unicast discovery providers are consulted

[Mark Brouwer <ma...@cheiron.org>]

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

Re: Order in which unicast discovery providers are consulted

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I did a quick scan (again) but I couldn't find any language from which I
> could conclude I was dealing with a bug

I'm thinking of the net.jini.security.Security and
net.jini.export.ServerContect specs, which say they use ordered lists
of providers, but the impl is using Service.providers.

- Bob

Re: Order in which unicast discovery providers are consulted

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
>> 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,
> 
> com.sun.jini.resource.Service is essentially a clone of sun.misc.Service
> from the JDK, and we retained its implementation search order, apparently
> not recognizing that it doesn't match what we have spec'd in various
> places as an ordered list to be maintained.

Hi Bob,

I did a quick scan (again) but I couldn't find any language from which I
could conclude I was dealing with a bug, I saw some implementation code
that gave me a hunch but then again
com.sun.jini.resource.Service.providers explicitly mentions that the
iterator returns the providers in an arbitrary order.

>                                             As of JDK 6, a public version
> of this facility has been exposed as java.util.ServiceLoader, which does
> preserve order.  Another bug to be fixed.

I'll file a bug against River and fix it in my code.
-- 
Mark

Re: Order in which unicast discovery providers are consulted

[Bob Scheifler <Bo...@Sun.COM>]

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

com.sun.jini.resource.Service is essentially a clone of sun.misc.Service
from the JDK, and we retained its implementation search order, apparently
not recognizing that it doesn't match what we have spec'd in various
places as an ordered list to be maintained.  As of JDK 6, a public version
of this facility has been exposed as java.util.ServiceLoader, which does
preserve order.  Another bug to be fixed.

- Bob