Why does JBoss always redeploy .WAR files that have already been deployed but not changed?

[alkoch]

Hello,

I am new to using the JBoss 7.1.1 server and am confused by a behavior that I have observed.

My JBoss server is deploying the six jBPM .war files (designer, drools-guvnor, jbpm-form-builder, jbpm-gwt-console, jbpm-gwt-console-server, jbpm-human-task-war) which I have placed in the .\jboss-as-7.1.1.Final\standalone\deployments folder.  When I launched the server for the very first time it detected these files and deployed them.  I see the deploymentNNN and tempNNN folders appear in the .\jboss-as-7.1.1.Final\standalone\tmp\vfs  folder.  This is similar to the behavior I'm familiar with from my use of the tomcat server.  I then shut the server down and observe that the two folders created in .\jboss-as-7.1.1.Final\standalone\tmp\vfs are retained but their contents are automatically deleted.  When I restart the server it once again deploys the six jBPM files into a new pair of folders in .\jboss-as-7.1.1.Final\standalone\tmp\vfs.  This is very surprising because no changes have been made to the six jBPM files and the problem is that this redeployment takes 3 to 4 minutes.  If this was just happening in a "production" environment then perhaps this would not be much of an issue.  However, I am trying to integrate the JBoss server into use with Eclipse Kepler in a development environment and having to wait 3 to 4 minutes for each code change and server launch is not practical.

1) Can anyone explain why JBoss goes to the trouble to redeploy files that have not been changed?

2) Is this a behavior that can be changed through a configuration setting?

Thank you,

Al

[sfcoy]

I think that you will find that it has to do it this way otherwise in order to cope with changes to the deployment directory between shutdown and startup.

You may not get this behaviour if you deploy the fixed components using the CLI, which does not use the deployments directory.

[alkoch]

Hi Stephen,

Thank you for your reply.

Based on your suggestion I 1st tried to deploy using the Admin console.  I removed the six jBPM war files from the deployment folder and then placed the files somewhere else.  Then I used the console to deploy each file one at a time.  I shut down the server and observed that the six "tempNNN" folders that had just been created using the console were deleted.  I then deleted the "source" war files and restarted the server and to my surprise the server was able to redeploy once again!  That left me with the question of how the server was able to redeploy after I had deleted the six war files as well as the question of how to stop the server from redeploying war files that have not been changed.

I then tried to follow your suggestion of using the command line interface.  Perhaps my problems are caused because I'm running under Windows but I was not able to deploy using this.  I ran jboss-cli.bat -- connect which gave me a CLI prompt then I issued the following deployment command and got the following error:

[standalone@localhost:9999 WARs] deploy C:\WARS\drools-guvnor.war

Exception in thread "management-client-thread 1-1" java.lang.OutOfMemoryError: Java heap space

As I originally stated, having JBoss redeploy each time it starts is a very bad problem because I need to launch JBoss out of Eclipse (Kepler) each time I need to debug a change to my code and it takes 3 to 4 minutes.  At this point I suppose my questions are:

1) I am curious – can you explain how JBoss was able to continue to redeploy war files that were originally deployed using the Admin console but that were subsequently deleted?

2) Are you surprised that JBoss shows this "redeployment" behavior when the original deployment was done using the Admin console?

3) Can you tell me how to do the deployment with the command line interface under Windows?

This is a very serious problem for me so I really appreciate your help.

Thank you,

Al

[sfcoy]

Why do you need to stop/restart the server at all?

Just leave it running.

[alkoch]

Hi Stephen,

My concern with the "auto-redeploy" behavior was triggered by my inability to do an initial server start up as part of debugging a web app in Eclipse (Kepler).  Since the six jBMP war files were always being deployed and that takes 3 to 4 minutes, each "re-deploy" was injecting 3 - 4 minutes into each edit/debug cycle of my code.  I don't know what was causing Kepler to not just redeploy only my changes and I don't know what has changed but I now seem to be able to do the initial launch of the server from Kepler with the initial 3 - 4 minute delay as jBPM starts up but now I can do an edit/debug cycle "instantly".  I'm still curious how I would tell JBoss to not redeploy war files that have not changed (the six jBPM war files), but at least I can use Kepler again!

I have found though that when I shut down the server from Kepler (so I can then shut down Kepler) that JBoss does not clean up the temp... and deployment... folders in jboss-as-7.1.1.Final\standalone\tmp\vfs. Then, when I next start the server back up from Kepler JBoss redeploys everything into a new pair of folders.  That leaves over 1GB of unused files.  Do that a couple of times and we crash from "out of disk space"!  Any idea why this is happening?

Also, can you tel me how to use the CLI under Windows so I can try your suggestion for how to stop the redeployment?  (See my prior response above).

Thank you for your help.

Al.

[sfcoy]

I vaguely recall that 7.1.1 used to leak disk space as you describe. Other users have also discovered this. It may be resolved in a newer release.

A newer release may also resolve the out of memory problem you're seeing when running the CLI deploy command.

Alternatively, try

set JAVA_OPTS="-Xmx128m"

before running jboss-cli.bat. I think the default is only 64m.