Description of problem: When running apply-updates.bat to patch the JON server, you can get "requested operation cannot be performed on a file with a user-mapped section open)" errors during patch application. Version-Release number of selected component (if applicable): 3.3.5 DR01. How reproducible: Most of the time. Steps to Reproduce: 1. Using 3.3.5 DR01 patch on windows, attempt to apply-update.bat on a JON server. 2. Monitor the patch log files to look for following exception 3. Actual results: >jon-server-3.3.0.GA-update-05\apply-updates.bat jon-server-3.3.0.GA > apply-updated_1-15-16_2324.txt java.io.FileNotFoundException: c:\temp\3n\jon-server-3.3.0.GA\bin\rhq-server.properties (The requested operation cannot be performed on a file with a user-mapped section open) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:221) at java.io.FileOutputStream.<init>(FileOutputStream.java:171) at java.io.FileWriter.<init>(FileWriter.java:90) at org.rhq.prod.UpdateProperties.processSecureSocketProtocol(UpdateProperties.java:185) at org.rhq.prod.UpdateProperties.main(UpdateProperties.java:285) Expected results: No exceptions during patch application and correct fixes applied to servers with invalid SSL settings. Additional info: See [BZ 1277389] for more details on invalid ssl settings.
This is fixed with commit: e827551d480a179b3a2 to jon.git. Moving to MODIFIED. The issue here was that the newest logic to fix https://bugzilla.redhat.com/show_bug.cgi?id=1277389 re-used an existing RHQ library to optionally modify properties. Even though the correct java file i/o operations were used to clean up the file handles, the windows operating system locks were sometimes taking a while to be cleaned up/garbage collected, triggering the "user-mapped section open" issues. There are several BZ's filed for this type of issue against the Sun/Oracle JDK for earlier 1.6 and earlier. Many were closed with no intention to fix because the problem was the underlying operating system file locking. See here as one example: http://bugs.java.com/view_bug.do?bug_id=4715154 The fix was to refactor the logic to instead handle all of the file I/O and be more careful about not triggering the windows file locking but still cleaning up the resources as is necessary. The new approach only uses BufferedReader/Writers and delays the use of the close() calls.
Moving to ON_QA for testing with the following build: https://brewweb.devel.redhat.com//buildinfo?buildID=474795 http://download.devel.redhat.com/brewroot/packages/org.jboss.on-jboss-on-parent/3.3.0.GA/75/maven/org/jboss/on/jon-server-patch/3.3.0.GA/jon-server-patch-3.3.0.GA.zip *Note: jon-server-patch-3.3.0.GA.zip maps to ER01 build of jon-server-3.3.0.GA-update-05.zip.
Verified on Version : 3.3.0.GA Update 05 Build Number : 4242930:1c9f74b