JDK-8027019 : Sometimes, codebase property is not written in .lap file in cache before loading app
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_8
  • CPU: x86_64
  • Submitted: 2013-10-22
  • Updated: 2015-06-03
  • Resolved: 2014-10-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u40 b12Fixed 9Fixed
Test machine: win8/x64

Steps to reproduce:
0 Login to sca00ahm.us.oracle.com
1 Install 32bit jre8-b112
2 Download http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/crystal/DO_NOT_REMOVE_ME/jrebug/vmargs/vmargs.zip and deploy it to your local server.
For sca00ahm.us.oracle.com, it has been deployed at C:\apache-tomcat-6.0.26\webapps\vmargs
3 Start tomcat server
4 Load jnlp which trys to pass vm args "-disableassertions" to VM using java-vm-args from local ip:
5 If jnlp fails to load with the following error, then this bug is reproduced(See attachment):
#### Java Web Start Error:
#### The field <jnlp>href has an invalid value: testsignedvmdisableassertions.jnlp

BadFieldException[ The field <jnlp>href has an invalid value: testsignedvmdisableassertions.jnlp,testsignedvmdisableassertions.jnlp]
	at com.sun.javaws.jnl.XMLUtils.getAttributeURL(Unknown Source)
	at com.sun.javaws.jnl.XMLFormat.parse(Unknown Source)
	at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
	at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
	at com.sun.javaws.CacheUtil.remove(Unknown Source)
	at com.sun.javaws.Main.uninstall(Unknown Source)
	at com.sun.javaws.Main.uninstallCache(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)

Detail trace:

1) this bug is not always reproducible. The test app can be loaded successfully sometimes.
2) If load the same app from remote server, the app can always be loaded successfully. Seems this issue only occurs when load with local server:
    If you load http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/crystal/DO_NOT_REMOVE_ME/jrebug/vmargs/jnlp/testsignedvmdisableassertions.jnlp, the app can be loaded successfully.


Affected tests: vmargsTest::testCMSInitiatingOccupancyFractionNegative vmargsTest::testDisableExplicitGCNegative vmargsTest::testMaxTenuringThresholdNegative vmargsTest::testNewRatioNegative vmargsTest::testUseCompressedOopsNegative vmargsTest::testdisablesystemassertionsNegative vmargsTest::testvmdaNegative vmargsTest::testCMSIncrementalDutyCycleMinNegative vmargsTest::testsignedNewRatio vmargsTest::testvmXfutureNegative vmargsTest::testvmesaNegative vmargsTest::testpropertySecure vmargsTest::testsignedCMSIncrementalPacing vmargsTest::testsignedNewSize vmargsTest::testsignedUseCompressedOops vmargsTest::testvmXbatchNegative JarUpdateTest::testExtensionJarUpdate

javaws -uninstall is synchronous now.

Thank you. Good to know javaws -uninstall will be synchronous, will try your fix when it's integrated. For the workaround of full path, in our testbed, almost all apps are launched with full path including javaws -uninstall, but seems issue still exists there.

I'm discussing the fix with the team now. Anyways there will be a way to make javaws -uninstall synchronous and it won't need no timeouts to complete before exiting the process. I'll let you know when I complete the fix. By the way. You asked what about the full path. When javaws is executed with the full path this issue does not exist because it works synchronously. And this is another workaround.

With your fix, do we still need the timeout workaround? if not, is there a way to make javaws -uninstall quit after it completes its tasks?

Correct. But there is a workaround now. You can put timeout between the two commands in the batch file for 2-5 seconds. 2 is enough.

if the problem is javaws -uninstall returns before it completes all its tasks, using full path or not doesn't really matter, right? With your fix, will it make sure javaws -uninstall return after it completes all tasks?

Crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UDEV-88

This happens only when launching javaws directly without using the full path. When such a command issued new process forked and the full path is used. This process fork does not wait for the process to terminate and asynchronously exist. When we have two command in the script such as: javaws -uninstall javaws some_url Then the second command start to execute before the first complete all it's tasks. So we run into a situation when the second process accesses the lap file and the first process erases the file.

Seems yes, at least it has much lower possibility to be reproduced than using javaws only. Tried with full path for around 10 times, can't reproduce it.

Can you please verify that this issue does not reproduce if in test.sh you use full path to javaws such as: "C:\Program Files (x86)\Java\jre1.8.0_40\bin\javaws.exe" -uninstall "C:\Program Files (x86)\Java\jre1.8.0_40\bin\javaws.exe" http://rehte.cn.oracle.com:8080/wshost/new_framework_exe/new_framework/tests/javaws/vmargs/jnlp/testNewRatioNegative.jnlp

Tried again, I still can reproduce it after deleting deployment log dir. And it can be reproduced on other machines like sc11136665.us.oracle.com(you can log in it by uadmin/changeme). mks and Far manager have been installed there for you to debug/fix. Hope it helps.

Looks like it's reproduced every second run. So the issue does exist. Will investigate.

I have difficulties reproducing it locally. To be able to fix it on leexlee I need environment to be setup there such as cygwin and a file manager (like Far manager).

Ok. I logged in to leexlee and cleared all deployment logs. And now this is not reproducible on leexlee either. Can't say what's the reason. There is another issue. Sometimes jnlp can't start because it's missing a cache entry. This maybe is a different issue. Closing as cannot reproduce.

Confirmed at leexlee.cn.oracle.com.

You can use the steps I posted in previous comment to reproduce. - Add http://rehte.cn.oracle.com:8080/ in ESL - Put following 2 lines in a script file like test.sh, and run it for several times, the issue should be able to be reproduced. javaws -uninstall javaws http://rehte.cn.oracle.com:8080/wshost/new_framework_exe/new_framework/tests/javaws/vmargs/jnlp/testNewRatioNegative.jnlp The app in this case is unsigned. You can login leexlee.cn.oracle.com qgong/hello to reproduce it. there is a test.sh in C:\Users\qgong We use tomcat because sometimes we have requirements other than just deploying stuff in server like using request filter to record http header

I ran it again for jdk9_b34 and got the following output: vmOptions - {some hashcode} in a window with title "SUCCESS". Wasn't able to get this BadFieldException. Can you provide the certificate you used for signing the jar ? And what's the reason of using tomcat ? Why don't you just run some simple http server, say python based ? Is it specific to windows 8 or also reproducible in windows 7 ? As the description suggests I should connect to sca00ahm.us.oracle.com which doesn't seem to be alive.

I can reproduce it with jre 9 b131. When this issue occurs, there is exception below in trace file java.net.MalformedURLException: no protocol: at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at com.sun.deploy.cache.Cache.isCacheEntryIPValid(Unknown Source) at com.sun.deploy.cache.Cache.getCacheEntryFromFile(Unknown Source) at com.sun.deploy.cache.Cache.getCacheEntryFromFile(Unknown Source) at com.sun.deploy.cache.CleanupThread.getCurrentCacheSize(Unknown Source) at com.sun.deploy.cache.CleanupThread.run(Unknown Source) I looked at the cache file in C:\Users\qgong\AppData\LocalLow\Sun\Java\Deployment\cache\6.0, it's because codebase property like codebase=http\://\:8080/vmargs/jnlp/ is not in ".lap" file Seems java tries to load app before .lap file is completely prepared. And it's not about local app, I can reproduce it with remote server. Add http://rehte.cn.oracle.com:8080/ in ESL Put following 2 lines in a script file like test.sh, and run it for several times, the issue should be able to be reproduced. javaws -uninstall javaws http://rehte.cn.oracle.com:8080/wshost/new_framework_exe/new_framework/tests/javaws/vmargs/jnlp/testNewRatioNegative.jnlp

I ran it several times on the mentioned machine with tomcat on and couldn't reproduce it. Please provide more reliable way to reproduce it or close it.

Does this only happen with Tomcat or have you tried a different server?

Affected tests: vmargsTest::testd3d vmargsTest::testdpiaware vmargsTest::testkeepAlive vmargsTest::testmultiplePropArgs vmargsTest::testnoerasebackground vmargsTest::testopengl vmargsTest::testpropertyOverwrite vmargsTest::testsignedCMSClassUnloadingEnabled vmargsTest::testsignedCMSIncrementalDutyCycleMin vmargsTest::testsignedCMSIncrementalMode vmargsTest::testsignedCMSMarkStackSize vmargsTest::testsignedCMSMarkStackSizeMax vmargsTest::testsignedDisableExplicitGC vmargsTest::testsignedMaxGCPauseMillis vmargsTest::testsignedMaxHeapFreeRatio vmargsTest::testsignedMaxInlineSize vmargsTest::testsignedMaxNewSize vmargsTest::testsignedMaxPermSize vmargsTest::testsignedParallelGCThreads vmargsTest::testsignedParallelRefProcEnabled vmargsTest::testsignedPrintCMSStatistics vmargsTest::testsignedPrintGCDetails vmargsTest::testsignedPrintGCTimeStamps vmargsTest::testsignedPrintHeapAtGC vmargsTest::testsignedPrintTenuringDistribution vmargsTest::testsignedReservedCodeCacheSize vmargsTest::testsignedSurvivorRatio vmargsTest::testsignedTraceClassUnloading vmargsTest::testsignedvmMaxDirectMemorySize vmargsTest::testsignedvmXbatch vmargsTest::testsignedvmXfuture vmargsTest::testsignedvmXmixed vmargsTest::testsignedvmXnoclassgc vmargsTest::testsignedvmXprof vmargsTest::testsignedvmXrs vmargsTest::testsignedvmXss vmargsTest::testsignedvmclient vmargsTest::testsignedvmda vmargsTest::testsignedvmdisableassertions vmargsTest::testsignedvmea vmargsTest::testsignedvmenableassertions vmargsTest::testsignedvmesa vmargsTest::testsignedvmshowversion vmargsTest::testsignedvmverbose vmargsTest::testuseSystemFontSettings vmargsTest::testvmXmixedNegative