3 Replies Latest reply on May 18, 2012 7:26 AM by alesj

    VFS exception on jar live update

    florinciu

      Hi,

       

      We have an automated process of updating the 'lib' directories on a number of JBoss servers. Most of our instances are running on JBoss AS 5.1.0 GA. and JBoss 4.0.4 GA.

      High availability is important to us. Is it safe to update the jar file in <jboss>/server/lib and <jboss>/common/lib while the servers are running and have the new jars loaded only on the next restart?

      Is there a best practice regarding this?

       

      ---

      AFAIK hot deployment/HDScanner operates on the <jboss>/server/deploy directories, when using the default config. Thus, the 'lib' directories are not hot deployable, however VFS still scans these directories and processes/caches the jars.

      The server logs contain some VFS warnings generated while trying to refresh the context of .jar files not completly copied to disk.

       

      Sample warning/exception:

      06:12:21,552 WARN  [ZipEntryContext] IGNORING: Failed to reinitialize context: vfszip:/usr/local/jboss-5.1.0.GA-Patch1/common/lib/axis.jar

      java.util.zip.ZipException: error in opening zip file

      Full stack trace: http://pastebin.com/8i0RMzn1

       

      Our tests show that functionality is not affected. Can someone confirm this?

      Is live update of jar files a safe process on JBoss >5.0 or JBoss 4.x(not having VFS)?

       

      Thanks.

        • 1. Re: VFS exception on jar live update
          alesj

          Hmmm, I don't see why not -- updating the lib/ jars on AS5.

          Although that zip error proves me wrong.

          It would be good to see the real cause of that error.

          • 2. Re: VFS exception on jar live update
            florinciu

            Hi Justin. Thanks for the input. It's pretty much inline with my inital 'hunch'. Good to have a confirmation.

             

            I think the zip error appears when VFS tries to open an invalid zip file(an incompletely copied jar). The exceptions appears more often on servers with a slower (cross-continetal) connection. We can reduce the frequency of the erro by doing an atomic update of the file so that the zip is not corrupted when the VFS refreshes its context.

            My main concern remains the fact that VFS is actively scanning the directories. I'm wonderign if after the change it loads any classes/beans that could make the server inconsistent. If yes, can this scaning be tweaked/disabled?

            • 3. Re: VFS exception on jar live update
              alesj

              I think the zip error appears when VFS tries to open an invalid zip file(an incompletely copied jar). The exceptions appears more often on servers with a slower (cross-continetal) connection. We can reduce the frequency of the erro by doing an atomic update of the file so that the zip is not corrupted when the VFS refreshes its context.

              Ah, ok, this explains it then -- and I actually suspected this. :-)

               

              My main concern remains the fact that VFS is actively scanning the directories.

              VFS is tnot scanning the directories. It simply checks if the jar file changed -- afair, it was a feature request.

               

              I'm wonderign if after the change it loads any classes/beans that could make the server inconsistent. If yes, can this scaning be tweaked/disabled?

              It can definitely lead to weird behavior -- e.g. removing some classes, but they  are still present in classloader, etc.

              It depends on what you're doing.

              1 of 1 people found this helpful