OCI 7.0.2 Java UI and Java version issues

[gmilazzoitag]

Hi,

some OCI 7.0.2 users are notifyng me that they're not be able to run Java UI from the "coffee cup" link on the OCI web portal in a lot of cases.

I know that Java 7 is a prerequisite but installing ONLY Java up to 7.21 it works but with newer versions up to 7.75 and 8.x the Java UI does not start at all.

Once clicked the button some seconds of wait and then nothing happen and in the task manager there's an appended java process.

This customer report me that they've some domain policies that automatically update their Java runtime versione so they cannot use the OCI Java UI.

Is there a way to let coexist older versions and the new Java one? 

Assuming they're forced to use the last one (i.e. 😎 are there some tricks?

Regards,

[ostiguy]

Hey Giacomo,

There is a server-side patch to OCI 7.0.2 that allows co-existance with Java 7/71-72-75 and 8u23-8u31 on the client side. Do you have that patch installed?

[gmilazzoitag]

Uh! I didn't know it! But also NetApp guys here did not know it 🙂

I will get from support.netapp.com download pages...

Thanks!

[gmilazzoitag]

Where's is this patch?

The last available is for 7.0.1 only (read in the notes)

[tflammger · Accepted solution]

Here's a workaround doc I wrote for my company for java compatability issues. You can have an older java version installed simultaneously with the "current" release and then use a windows shortcut to invoke that java directly against the server. The coffe cup UI will not work, but a deskop shortcut is actually more convenient anyway. 😉

[gmilazzoitag]

Thanks.

Now I've tagged as a solution your answer but if it fails I will untag it 

[ostiguy]

We don't have individual patches available on support.netapp.com - it can be obtained via a support case

[tflammger]

If my boss can follow it, you should be ok. 

[PeteHanson]

ok so i have a windows 8.1 desktop with Java 7 build 60 64 bit installed

been battling this issue described in the article here and have tried the workarounds but no luck - not the exact same error but getting a different one:

Exception

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://servername/client/app/http-client.jnlp
 at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
 at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
 at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
 at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
 at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
 at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
 at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
 at com.sun.javaws.Launcher.launch(Unknown Source)
 at com.sun.javaws.Main.launchApp(Unknown Source)
 at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
 at com.sun.javaws.Main.access$000(Unknown Source)
 at com.sun.javaws.Main$1.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

wrapped exception:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
 at sun.security.ssl.Alerts.getSSLException(Unknown Source)
 at sun.security.ssl.Alerts.getSSLException(Unknown Source)
 at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
 at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
 at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
 at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
 at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
 at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
 at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
 at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
 at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
 at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
 at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
 at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
 at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)
 at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
 at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
 at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
 at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
 at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
 at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
 at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
 at com.sun.javaws.Launcher.launch(Unknown Source)
 at com.sun.javaws.Main.launchApp(Unknown Source)
 at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
 at com.sun.javaws.Main.access$000(Unknown Source)
 at com.sun.javaws.Main$1.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

I would assume with all the vulnerabilities being shown for older java versions and MS activex blocking that OCI will be forced to upgrade to a newer version of supportable java - is this in the works? or even get rid of java completely? 🙂

i have created the shortcut listed here a few different times but its the shortcut getting this alert - any ideas?

[ostiguy]

Hey Pete,

What version of OCI are you running? Has the OCI client ever worked from the machine? What you are seeing is a SSL/TLS negotiation problem. Is your workstation configured with any non-default Java settings for TLS/SSL ?

If you drop to a cmd prompt, and

ping servername

Does that resolve to the right IP address?

You may also want to drill into Control Panel -> Programs -> Java. In the Java Control Panel, you may want to review the network connection settings - are you going through a proxy? Should it be?

[PeteHanson]

Thanks for the prompt response

we are running OCI version 7.0.2 build 164 so it should be pretty up to date

as for the java client no it has never worked from this machine

as for the pinging of the server (I changed the name) we can open up the web client without issues and i can ping the server

i am running standard java settings but have tried to set non-standard ones - i am not the only one having this issue as our entire team here has the same errors when launching the client

when i open a command prompt and ping the server name it does reply and resolves to the correct IP

my java is not going through a proxy server

[ostiguy]

Does the Java client work on the OCI server itself?

If you are sending OCI ASUP, PM me the site name, and I will poke through the logs

Things to try

Java Control Pnael

General -> Temporary Files Settings -

make sure disk space is not set to none for caching files -that causes weird behavior.

Delete Files -> Enable all three check boxes -> click Ok - this will clear out the client side cache - if you re-launch the Java UI from the OCI WebUI, it will re-download the client entirely as none of its bits will be cached locally - this sometimes clears up client pain

Advanced

 Enable Tracing

 Enable Logging

Check those two checkboxes before launching the Java client - it will generate more logging into

c:\users\matt\AppData\LocalLow\Sun\Java\Deployment

Where "matt" is your Windows username.

[PeteHanson]

yes it does

[PeteHanson]

OK i missed a second part of your question

the checkbox for temporary files is checked on my computer

all 3 boxes were checked

the advanced settings were checked already so i will take a look at the file in appdata to see if it shows anything

[PeteHanson]

here is the java trace file generated when i open the link remotely:

Log started: Tue, 24 Mar 2015 13:14:55 -0500
Java Web Start 10.67.2.01
Using JRE version
 1.7.0_67-b01 Java HotSpot(TM) Client VM
#### Java Web Start Error:
#### Unable to load resource: https://servername:443/client/app/http-client.jnlp

i tried adding in the exact link on the OCI server for this that does work and had no luck - is it related to the version of java?

[ostiguy]

Highly doubtful.

The way the Java client works is roughly as follows:

Download JNLP file via https

Parse JNLP file - download code via HTTPS

Bootstrap client

Client initiates https connection to server

You are basically stuck at roughly phase 1, or the start of 2.

It doesn't make much sense why you can download the JNLP via a browser, and then get this error message, unless the browser has a different communication path to the OCI server from what Java would have, but it sounds like we have ruled this out as no proxies are in use with the browser or Java.

PM me your OCI ASUP site name if you are sending us extended logs, and I can see if anything interesting is happening server side