Hi Larry,
I was able to reproduce the same error locally and can confirm that it's the proxy setting in java control panel that's the root cause. The problem is same as this
Sun problem report.
To understand why it happens, I have to explain little about RMI.
A frequent complaint cited against all the common distributed technologies - RMI, CORBA, DCOM - is that firewalls typically block their communications.
Sun anticipated this problem and provided for HTTP tunneling for RMI - i.e, RMI communication can be wrapped in HTTP packets, since HTTP is usually allowed by firewalls.
The important point to note is, this HTTP tunneling is engaged when a proxy server is specified. Same applies for HTTPS.
This
article explains it well.
RMI uses the concept of socket factories to set up the tunneling.
The socket factories concept is also needed if the network transport needs to be customized - for example, running RMI over SSL connections.
In the SSL case
with proxy configured, the java web start plugin detects that there is a proxy and installs a socket factory that can do tunneling.
The Acme client app then runs, downloads a file 'comMode.conf' and realises it should use SSL encrypted RMI.
So it tries to install its own custom socket factory that provides RMI over SSL, using the 'RMISocketFactory.setSocketFactory()' method and fails.
It fails because once the VM-wide socket factory has been set, it can't be changed.
It looks like the app has been designed to continue even if this fails.
So, we now have a client that has been unable to setup RMI over SSL, and has fallen back to using unencrypted RMI.
But on the other end, the server is probably ok and expecting encrypted RMI communication.
The two don't understand each others data, and that's why so many 'non-JRMP server at remote endpoint' errors, null remote object references and code download errors (as observed by the proxy engineer) are seen in the https trace file.
In the SSL case
without proxy, the java web start plugin detects no proxy and doesn't first install a socket factory for tunneling.
That's why Acme client app's attempt to install one succeeds and it's able to proceed normally.
In the non-SSL unencrypted case
without proxy, the java web start plugin detects no proxy and doesn't first install a socket factory for tunneling.
That's why Acme client app's attempt succeeds and it's able to proceed normally.
In the non-SSL unencrypted case
with proxy, the java web start plugin will install a socket factory for tunneling.
But the Acme client app will not attempt to install its own socket factory (attempt is made only if comMode.conf specifies SSL),
and so it's able to proceed normally.
Solutions:
- I feel this is a bug in Acme client app. It should anticipate that a VM-wide socket factory may already have been installed, and should be changed to use the per-remote-object RMIServerSocketFactory and RMIClientSocketFactory facility described in the problem report. This approach worked in my experiments.
- As workarounds for you, one of these may work:
- Set Java control panel to always use browser settings, and specify proxy configuration file only in browser.
- Set Java control panel to always use direct connection, if server is local server.
- Unset the proxy host setting at runtime by setting '-Ddeployment.proxy.http.host=' in the Java Control Panel > Java > View > Runtime Parameters column. Note that this setting will override for all java web start apps and applets.
Cheers
Karthik
