tags:

views:

166

answers:

2

This instance of JBoss deploys several war files. The rest of the JBoss startup takes about 5 minutes or less. But when it gets to one particular war file, startup just hangs with no further output to the jboss log. It waits there for about 15 minutes and then suddenly the war starts deploying. The rest of the JBoss startup is then fine.

What I want to know is what steps do you recommend I take to diagnose the cause of this condition?

It is not possible to upgrade this site to a newer version of JBoss nor java (currently 1.5.0.7). It is running on 32-bit CentOS 5.3 Linux on 3 xen-based virtual servers in a load balanced configuration. The code is common to all three servers via an nfs share. This same issue was seen, however, when the 3 servers were physical and the code was local to each server. The servers are each 2 cpu, 4GB RAM servers.

Also as an FYI, the wars that deploy in this instance of JBoss are actually exploded wars contained in directories within the deploy directory.

+2  A: 

Chances are, jBoss is unpacking the war file to the tmp directory. This will take a while on a machine with a slow disk or if the war is large. Try explodig it in the deploy directory. Here's a wiki on the topic, but the short version is create a directory with the name of the war, including the .war at the end, and unzip the contents into that. It'll be something like %JBOSS_HOME%\server\<instance>\deploy\<war_file>.war.

sblundy
Thanks for the answer. I should have mentioned that the war is already exploded as are the others that load in this JBoss instance. I'll update the question with this information.
dkblinux98
@dkblinux98 : really? You might want to delete tmp and start it up to see if jBoss is copying/exploded anything else there.
sblundy
+2  A: 

What I want to know is what steps do you recommend I take to diagnose the cause of this condition?

First of all 15 minutes are a typical timeout delay, maybe trying to access a network resource.

  • 1st strace -p pid to find out what the server is doing (system calls)

  • 2nd create a few thread dumps during idle time to find out where it gets stuck.

  • 3rd check $JBOSS_HOME/bin/run.conf for JAVA_OPTS for weird changes.

stacker
Thanks for the suggestions. I will try them and report back.
dkblinux98
So this is the answer that led me to the solution. Turns out the problem child is an ear rather than a war. There are symbolic links within the exploded ear directory which point to lots and lots of files (think 20GB). With each deployment of the ear, all of those symbolically linked files are being copied from their real location to jboss tmp. Unfortunately the underlying code for the website references the symbolic link in a way that makes it difficult to remove without code changes. So that is the next step. Thanks folks for the fast replies and good advice.
dkblinux98