JDK-6636732 : launching 2 different consumer JRE's of the same family in parellel has issues.
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2007-12-03
  • Updated: 2010-10-21
  • Resolved: 2010-10-21
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.
JDK 7
7Resolved
Related Reports
Duplicate :  
Relates :  
Description
Steps to reproduce:

1. launch 6u10 consumer JRE installer
2. when the 6u10 consumer JRE installer is showing the license agreement, launch a dummy 6u11 consumer JRE installer.
3. This will likely lead to a 1722 error, because both 6u10/6u11 installer will download the full consumer JRE

Comments
EVALUATION The problem / scenarios is larger than it seemed. We need to handle multiple online installs, multiple offline installs, or mix of online and offline installs. The installs could be consumer, jre1.6.0_10-c.msi, and/or static, jre1.6.0_10-s.msi. Also, it looks like there is an issue: if you install jre1.6.0_10-c.msi, after it completes successfully, you can then directly install jre1.6.0_10-s.msi without any error being displayed and end up with an unsupported configuration.
29-05-2008

SUGGESTED FIX Need a better solution. The parent could be our online or offline installer, the JDK installer when installing a public JRE, or a corporation's software distribution mechanism. We could get false errors if we errored if we found an msiexec with an command line containing an msi file starting with jre or java. Another MSI named jrecord or javalanche could installing us silently. Also corporations using a software distribution mechanism could rename the msi. Maybe instead of blocking the scenario, detect that a problem may be encountered (e.g. Error 25099) and report a specific error before putting the system into an unknown state.
15-04-2008

EVALUATION The FilesInUse dialog: Java Setup - Close Applications The applications listed are currently running and must be closed to allow the install to proceed. msiexec.exe was a fluke. I was not able to reproduce it. It must be milliseconds between clicking next to start the first install and when HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress is created and causes Error 1500 in the second install. Our problem is with two JRE installs racing between the launch of the MSI and the install execute sequence. Only one MSIs install execute sequence can run at a time. This is what causes Error 1500. AppSearch and FindRelatedProducts are not executed during the install execute sequence if already done on the client side during the install UI sequence. How do we check if any jre msi installations are running? I've seen: msiexec.exe:2940 Command line: "C:\WINDOWS\system32\\msiexec.exe" /i "C:\Documents and Settings\Administrator\Application Data\Sun\Java\jre1.6.0_10\jre1.6.0_10-c.msi" TRANSFORMS="C:\Documents and Settings\Administrator\Application Data\Sun\Java\jre1.6.0_11\sp1033.MST" ED=0 SPWEB=http://j2se.east.sun.com/arc/1.6.0_10/pit/2008-02-22.15_43/windows-i586/iftw/sp METHOD=jother COUNTRY=US parent: jre-6u11-windows-i586-p-iftw.exe(3996) launched msi from folder msiexec.exe:2940 Command line: "C:\WINDOWS\System32\msiexec.exe" /i "C:\Documents and Settings\Administrator\Desktop\2008-02-22 b13\jre1.6.0_10-c.msi" parent: explorer.exe The parent could be our online or offline installer, the JDK installer when installing a public JRE, or a corporation's software distribution mechanism. We could get false errors if we errored if we found an msiexec with an command line containing an msi file starting with jre or java. Another MSI named jrecord or javalanche could installing us silently. Also corporations using a software distribution mechanism could rename the msi. Maybe instead of blocking the scenario, detect that a problem may be encountered (e.g. Error 25099) and report a specific error before putting the system into an unknown state.
28-02-2008

EVALUATION Using 6u10 and 6u11 from b13 pit: 6u10: http://j2se.east/plugin/1.6.0_10-pit/2008-02-22.08_28/ 6u11: http://j2se.east/plugin/1.6.0_10-pit/2008-02-22.15_43/windows-i586/ Ran jre-6u10-windows-i586-p-iftw.exe. While stopped at the license agreement, ran jre-6u11-windows-i586-p-iftw.exe started 6u10 install With b13 when I started the 6u11 install before 6u10 completed, I got our FilesInUse dialog (not Error 1500): Java Setup - Close Applications The applications listed are currently running and must be closed to allow the install to proceed. msiexec.exe [Retry] [Quit] If click Retry after 6u10 completed: "Error 25099. Unzipping core files failed." java_install.log contained: extracting: bin/jqs.exeError:fopen: while opening file <bin/jqs.exe> Still evaluating...
27-02-2008

EVALUATION Using 6u10 and 6u11 from 2008-02-20. Ran jre-6u10-ea-windows-i586-p-iftw.exe. While stopped at the license agreement, ran jre-6u11-windows-i586-p-iftw.exe started 6u10 install If start 6u11 install before 6u10 complete: "Error 1500. Another installation is in progress. You must complete that installation before continuing this one." [Retry] [Cancel] If click Retry after 6u10 complete: "Error 25099. Unzipping core files failed." java_install.log contained: extracting: bin/jqs.exeError:fopen: while opening file <bin/jqs.exe> I want to retest with b13 and changes for 6626922: PIP breaks if processes that lock Java are opened after FileInUse detection, but before patching
26-02-2008

SUGGESTED FIX One suggestion I have is for the .exe to check if any JRE msi installations are running, and pop up a warning telling the user that another installation is already in progress.....and to rerun the .exe at a later time.
03-12-2007