-
1. Re: EAR deployment uses old jar file
jaikiran Sep 19, 2011 4:12 AM (in response to zeitcheist)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 Sep 20, 2011 8:58 PM (in response to jaikiran)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 Sep 22, 2011 12:11 AM (in response to zeitcheist)Has anyone experienced this weird behavior of JBoss?
-
4. Re: EAR deployment uses old jar file
zeitcheist Oct 11, 2011 12:54 AM (in response to zeitcheist)Anyone?
-
5. Re: EAR deployment uses old jar file
starver Oct 15, 2011 1:04 PM (in response to zeitcheist)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.