glassfish
  1. glassfish
  2. GLASSFISH-14623

Error renaming domain.xml to domain.xml.bak on (slow) Windows system

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_ms07
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: Windows (generic)
      Platform: All

    • Issuezilla Id:
      14,623

      Description

      While running deployment devtests on a (slow) Windows system, I saw the error
      below recur several times during a 35-minute test run.

      I do not know if the slowness of the laptop I was using helps expose this
      problem or not.

      Even if this problem cannot be fixed, is there a way to display the temp file
      which does contain the updated config in the error message so the user could
      manually recover the config changes (if we even want to suggest that)?

      #|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Could
      not rename
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
      to
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak|#]

      [#|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|IOException
      while saving the configuration, changes not persisted
      java.io.IOException: Could not rename
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
      to
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak
      at
      com.sun.enterprise.v3.server.DomainXmlPersistence.save(DomainXmlPersistence.java:192)
      at
      org.glassfish.config.support.GlassFishDocument$1.transactionCommited(GlassFishDocument.java:90)
      at
      org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:341)
      at
      org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:332)
      at
      org.jvnet.hk2.config.Transactions$ListenerNotifier$1.call(Transactions.java:208)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      at org.jvnet.hk2.config.Transactions$Notifier$1$1.run(Transactions.java:162)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      at
      java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at
      java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:619)

      #]

      [#|2010-11-11T11:48:47.843-0600|SEVERE|glassfish3.1|javax.enterprise.system.core.org.glassfish.config.support|_ThreadID=16;_ThreadName=Thread-1;|CONFIG0100:Exception
      Could not rename
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml
      to
      C:\tim\asgroup\v3\b28\publish\glassfish3\glassfish\domains\domain1\config\domain.xml.bak
      while persisting domain.xml, changes will not be available on server restart|#]

        Activity

        Hide
        Tom Mueller added a comment -

        Please provide more details on how to reproduce this problem. What test was being
        run? Did you have the domain.xml file open in an editor while running the test?
        Was the test doing anything with the domain.xml file?

        Even with a slow system, we should not be seeing this problem with the locking
        that we have in place for reading and writing the domain.xml file.

        Show
        Tom Mueller added a comment - Please provide more details on how to reproduce this problem. What test was being run? Did you have the domain.xml file open in an editor while running the test? Was the test doing anything with the domain.xml file? Even with a slow system, we should not be seeing this problem with the locking that we have in place for reading and writing the domain.xml file.
        Hide
        Tim Quinn added a comment -

        Perhaps not surprisingly I've found this to be an intermittent problem. In the
        additional test I just ran I saw at least one error like this in each two or
        three runs of a small test suite.

        1. Make sure you have an up-to-date appserv-tests/devtests/deployment directory
        tree.

        2. cd appserv-tests/devtests/deployment/war/servletonly

        3. asadmin start-domain

        4. ant all

        5. Look in the server.log file.

        The results displayed at the client sometimes show all PASSes even if there was
        a problem with backing up domain.xml internally in the DAS.

        The tests do not manipulate domain.xml beyond what the DAS does internally as it
        operates.

        Of course the speed of the system should not affect this. I mentioned it
        because the system I used for testing is probably quite a bit slower than most
        and faster systems might not show the problem, esp. given that it's intermittent.

        I did not have domain.xml open in an editor, but it's entirely possible that the
        anti-virus software running on my system had it open.

        I'm using my personal (old, slow) Windows laptop which runs, among other things,
        an auto-protect virus scanner which (according to what I've read about it) will
        check each file as it's read or written. So I disabled that feature temporarily
        for a few test runs. I did not see this error while I had auto-protect off.

        I turned auto-protect back on and saw the error on my second run of the
        war/servletonly tests.

        This is not conclusive, obviously, but it's a plausible explanation. If this is
        what's happening, then I would guess it's less likely to happen with faster more
        modern systems. This is partly why much of the deployment code uses
        FileUtils.renameFile which retries on Windows if the operation fails. There's
        not currently a corresponding method there for deleting with retry but it'd be
        easy enough to add.

        Show
        Tim Quinn added a comment - Perhaps not surprisingly I've found this to be an intermittent problem. In the additional test I just ran I saw at least one error like this in each two or three runs of a small test suite. 1. Make sure you have an up-to-date appserv-tests/devtests/deployment directory tree. 2. cd appserv-tests/devtests/deployment/war/servletonly 3. asadmin start-domain 4. ant all 5. Look in the server.log file. The results displayed at the client sometimes show all PASSes even if there was a problem with backing up domain.xml internally in the DAS. The tests do not manipulate domain.xml beyond what the DAS does internally as it operates. Of course the speed of the system should not affect this. I mentioned it because the system I used for testing is probably quite a bit slower than most and faster systems might not show the problem, esp. given that it's intermittent. I did not have domain.xml open in an editor, but it's entirely possible that the anti-virus software running on my system had it open. I'm using my personal (old, slow) Windows laptop which runs, among other things, an auto-protect virus scanner which (according to what I've read about it) will check each file as it's read or written. So I disabled that feature temporarily for a few test runs. I did not see this error while I had auto-protect off. I turned auto-protect back on and saw the error on my second run of the war/servletonly tests. This is not conclusive, obviously, but it's a plausible explanation. If this is what's happening, then I would guess it's less likely to happen with faster more modern systems. This is partly why much of the deployment code uses FileUtils.renameFile which retries on Windows if the operation fails. There's not currently a corresponding method there for deleting with retry but it'd be easy enough to add.
        Hide
        Tom Mueller added a comment -

        Suggested fix: replace uses of File.renameTo in DomainXmlPersistence.java with
        FileUtils.renameFile which includes the retry for windows.

        Show
        Tom Mueller added a comment - Suggested fix: replace uses of File.renameTo in DomainXmlPersistence.java with FileUtils.renameFile which includes the retry for windows.
        Hide
        Tom Mueller added a comment -

        Fixed per the suggested fix in revision 42984.

        Tim, can you try this again on your system. Since I can't reproduce this in my
        environment, I can't say for sure that this actually fixed the problem.

        Show
        Tom Mueller added a comment - Fixed per the suggested fix in revision 42984. Tim, can you try this again on your system. Since I can't reproduce this in my environment, I can't say for sure that this actually fixed the problem.
        Hide
        allycavs added a comment - - edited

        Hey Guys

        This is definetely an anti virus problem for me. If others have the same issue, look to switch off automated file protection on your anti virus. Look for an option that scans all files after a save and switch this option off. reboot aswell. My antivirus didnt tell me to reboot but the change only took effect after a reboot

        Thanks
        Alan

        Show
        allycavs added a comment - - edited Hey Guys This is definetely an anti virus problem for me. If others have the same issue, look to switch off automated file protection on your anti virus. Look for an option that scans all files after a save and switch this option off. reboot aswell. My antivirus didnt tell me to reboot but the change only took effect after a reboot Thanks Alan

          People

          • Assignee:
            Tom Mueller
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: