5 Replies Latest reply on Oct 15, 2011 1:04 PM by starver

    EAR deployment uses old jar file

    zeitcheist

      Hi!

       

      I am new to JBOSS config. Problem is, our application seems to use old jar.

       

      We are using JBoss 5.1.0GA, on a CentOS server.

       

      Here are what I have found out.

       

      Since we are deploying an EAR file, I thought it is exploded into tmp/deploy dir, but that's not the case. After checking the other directories, I found the jar file under /tmp/vfs-nested.tmp directory.

       

      I find it weird, there are three "renamed" jar files pertaining to what I am telling all along, from now on let's assume it is Commons.jar. Under vfs-nested, the three "created" jars are named:

           xxx_Commons.jar

           yyy_Commons.jar

           zzz_Commons.jar

       

      I extracted all those three. One of them still has the old class file. I confirmed it by opening the .class files of the three jars. The other two have the updated versions.

       

      So i tried deleting those files, first just those under vfs-nested, restarted JBOSS, but still it created the three jars, one still the old version. Then I deleted all files under tmp directory, restarted JBOSS, but still failed. By the way, the EAR file under deploy is the updated one, I know, I extracted it also and the Commons.jar is updated.

       

      I have the following questions:

       

      1. Why not explode into /tmp/deploy directory?

       

      2. Why, under vfs-nested.tmp, is the JBOSS creating three jars, while in fact, we are using only one copy in the EAR file?

       

      3. Why is the JBOSS still using the old jar file?

       

      Message was edited by: zeitcheist

        • 1. Re: EAR deployment uses old jar file
          jaikiran

          How do you redeploy? And what do you see in your application which shows that the old jar is being used?

          • 2. Re: EAR deployment uses old jar file
            zeitcheist

            How do you redeploy?

            Hot deploy. Actually, we use Jenkins, which basically builds our application and writes the ear file to the deploy directory.

             

            And what do you see in your application which shows that the old jar is being used?

            Exception. NoSuchMethodError. We modified one of the superclasses, added one method. Modified client classes that use those subclasses of the first. When the client objects are invoked, the exception occurs. I checked the jars in vfs-nested.tmp, and one of those copies still holds the older version of the superclass.

            • 3. Re: EAR deployment uses old jar file
              zeitcheist

              Has anyone experienced this weird behavior of JBoss?

              • 4. Re: EAR deployment uses old jar file
                zeitcheist

                Anyone?

                • 5. Re: EAR deployment uses old jar file
                  starver

                  I have seen this behavior during hot deploy. In our case, we had code that could not be garbage collected so the ear/war could not be successfully undeployed. An old instance of the ear/war remained after hot deploying the new code and the old still answered requests. When inspecting the vfs, I found several copies of the same artifacts with different prefixes as you describe - sounds like the same thing.

                   

                  Basically, anything that stops garbage collection can break hot deploy. This includes things like have a background thread in a bean that never terminates, using java timers that reschedule themselves instead of Quartz or EJB timers, or a monitoring system that continually pinged a web service so that the old code could never age out gracefully. I have seen some advice in the community to turn off hot deploy which is what we did because there was so much code that needed to be fixed. Of course this won't work for your Jenkins setup.

                   

                  You could create a test JBoss engine and try to resolve the hot deploy issues. Using any of the default configurations, you can simply copy your artifact to the server/xxx/deploy directory to initiate a hot deploy. Then watch the logs for indication of a successful undeploy/redeploy. You should delete the tmp/data/work directories prior to each restart to ensure a clean starting point. Finding the offending code is simply a manual code review.