Java Server hängt beim Start in Centos 5

Question

Also, ich betreibe einen Webserver mit Embedded Jetty und dem Maven App-Assembler-Plugin. Wenn ich die App-Assembler-App direkt aufruft (läuft als root), startet der Server gut. Selbst wenn man unter Nohup läuft, läuft der Webserver völlig in Ordnung.

Wenn ich das App-Assembler-Skript als init.d-Skript (Runlevels 235/Start pri 98/Stop pri 20) registriere und das Skript init.d mit dem Befehl service ausfühle, bleibt der Webserver beim Start hängen.

Der Ort, an dem die Anwendung hängt, ist während des Klassenpfad-Scans im Struts 2 Convention-Plugin.

Wenn ich den Web-Server mit ‚töten -quit‘ töten, sieht der Code wie es in Unix-Dateisystem bleibt:

"main" prio=10 tid=0x09add800 nid=0xb33 runnable [0xb7361000] 
    java.lang.Thread.State: RUNNABLE 
     at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) 
     at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) 
     at java.io.File.isDirectory(File.java:754) 

ich einige der Forschung getan haben, und es scheint, dass es möglicherweise Leistungsprobleme sein mit NFS, Java und Dateisystemzugriff.

Das Problem, das ich habe, ist, dass wir nicht NFS auf unserem Server laufen, und dass, soweit ich weiß, wir die App auf die gleiche Weise vom selben Benutzer laufen.

Auch wenn der Weg, den Dienst Befehl mimmt (Ausführen von "env -i" vor dem Skript startet), nicht direkt das Skript ausgeführt wird.

Suchen Sie nach Ratschlägen oder Hinweisen zur Lösung dieses Problems oder einer anderen Möglichkeit, es zu umgehen.

-Update (4/8/12)

Ich bin mit Sun (Oracle) JDK 1.6.0_31

/usr/java/latest/bin/java -version 
java version "1.6.0_31" 
Java(TM) SE Runtime Environment (build 1.6.0_31-b04) 
Java HotSpot(TM) Server VM (build 20.6-b01, mixed mode) 

Answer 1

So, dachte ich, das Problem aus. Es sieht so aus, als ob die Probleme, die ich mit den Threads sah, die in Dateisystemoperationen festhängen, auf rekursive Symlinks zurückzuführen sind, denen Java auf unbestimmte Zeit folgen wird. Jeder Scan von der Wurzel eines Unix-Systems, der Symlinks folgt, sollte zu dem gleichen Problem führen (100% CPU-Auslastung und das Scannen der Datei hängt ab).

Das Problem bestand letztlich darin, dass das Dienstskript von root ausgeführt wurde, wo der Aufruf des Skripts direkt von meinem aktuellen Arbeitsverzeichnis gestartet wurde. Ich habe mein Startskript geändert, um den Stamm des app assemblierten Skripts vor dem Ausführen zu verschieben, und alles ist gut.