Ich versuche herauszufinden, was a verursachen würde1 Minute Verspätung beim Start von Jetty. Handelt es sich um ein Konfigurationsproblem, meine Anwendung oder etwas anderes?

Ich habe Jetty 7 (jetty-7.0.1.v20091125, 25. November 2009) auf einem Server installiert und stelle eine 45 MB ROOT.war-Datei im Verzeichnis webapps bereit. Dies ist die einzige Webanwendung, die in Jetty konfiguriert ist. Ich starte dann Jetty mit dem Befehl:

java -DSTOP.PORT=8079 -DSTOP.KEY=mystopkey -Denv=stage -jar start.jar etc/jetty-logging.xml etc/jetty.xml &

Ich erhalte gleich danach zwei Ausgabezeilen:

2010-03-07 14:20:06.642:INFO::Logging to StdErrLog::DEBUG=false via org.eclipse.jetty.util.log.StdErrLog
2010-03-07 14:20:06.710:INFO::Redirecting stderr/stdout to /home/zing/jetty-distribution-7.0.1.v20091125/logs/2010_03_07.stderrout.log

Wenn ich die Eingabetaste drücke, erhalte ich meine Eingabeaufforderung zurück. Wenn ich die Protokolldatei (logs / 2010_03_07.stderrout.log) betrachte, sehe ich am Anfang Folgendes:

2010-03-07 14:08:50.396:INFO::jetty-7.0.1.v20091125
2010-03-07 14:08:50.495:INFO::Extract jar:file:/home/zing/jetty-distribution-7.0.1.v20091125/webapps/ROOT.war!/ to /tmp/Jetty_0_0_0_0_8080_ROOT.war___.8te0nm/webapp
2010-03-07 14:08:52.599:INFO::NO JSP Support for , did not find org.apache.jasper.servlet.JspServlet
2010-03-07 14:09:51.379:INFO::Set web app root system property: 'webapp.root' = [/tmp/Jetty_0_0_0_0_8080_ROOT.war___.8te0nm/webapp]
2010-03-07 14:09:51.585:INFO::Initializing Spring root WebApplicationContext
INFO  - ContextLoader              - Root WebApplicationContext: initialization started
INFO  - XmlWebApplicationContext   - Refreshing Root WebApplicationContext: startup date [Sun Mar 07 14:09:51 PST 2010]; root of context hierarchy
...

Beachten Sie die 1-minütige Pause zwischen der 3. und 4. Zeile. Was macht Jetty zu diesem Zeitpunkt? Welche anderen Dinge könnten vor sich gehen? Es sieht noch nicht einmal so aus, als hätte meine Frühlingsinitialisierung bereits begonnen.

Beachten Sie, dass ich in meinem Verzeichnis / tmp nachgesehen habe, ob es einfach an der Zeit war, meine Kriegsdatei zu entpacken. Die Datei wurde jedoch bereits zu Beginn dieser einminütigen Verzögerung vollständig entpackt.

AKTUALISIEREN:

Dank Vorschlägen habe ich die DEBUG-Protokollierung hinzugefügt. Ich fand, dass ungefähr 2 Sekunden verwendet wurden, um die Kriegsdatei zu extrahieren. Aber dann gibt es ungefähr 41 Sekunden VerspätungStarten Sie SecureRandom:

2010-03-07 21:54:45.414:DBUG::Starting SessionHandler@79884a40@
2010-03-07 21:54:45.414:DBUG::Starting org.eclipse.jetty.server.session.HashSessionManager@5fe8ce8
2010-03-07 21:54:45.416:DBUG::Container org.eclipse.jetty.server.Server@35175422 + org.eclipse.jetty.server.session.HashSessionIdManager@1d96f4b5 as sessionIdManager
2010-03-07 21:54:45.416:DBUG::Starting org.eclipse.jetty.server.session.HashSessionIdManager@1d96f4b5
2010-03-07 21:54:45.416:DBUG::Init SecureRandom.
2010-03-07 21:55:26.244:DBUG::STARTED org.eclipse.jetty.server.session.HashSessionIdManager@1d96f4b5
2010-03-07 21:55:26.247:DBUG::STARTED org.eclipse.jetty.server.session.HashSessionManager@5fe8ce8
2010-03-07 21:55:26.248:DBUG::Starting ConstraintSecurityHandler@6b9cd75a@
2010-03-07 21:55:26.261:DBUG::Starting ServletHandler@62c2ee15@

Was ist SecureRandom und warum würde es diese Verzögerung verursachen?

LÖSUNG:

Es sieht so aus, als hätte ich ein Problem mit meinemSystem hat nicht genug Last. Ich habe dies gerade als neuen Staging-Server eingerichtet, und außer mir wird es von niemandem verwendet. Das System verfügt also nicht über genügend Entropie, damit der Zufallszahlengenerator schnell genug Zufälligkeit erzeugt.