World Map
Java Service Wrapper ist der einfachste Weg, um Ihr Produkt zuverlässiger, sicherer zu machen.
  • Free Trial
  • Buy Now
Troubleshooting

Troubleshooting: Probleme

Troubleshooting: Probleme

Mein Programm läuft nicht so schnell, wie ich erwartet habe.

Im Allgemeinen sollte eine Anwendung so schnell unter dem Wrapper läufen, wie es eigenständig läuft. Here sind ein paar Dinge, die überprüft werden sollten.

Konsolenausgabe

Auf einigen Plattformen, inklusive Windows, bewirkt das Senden großer Textmengen an System.out oder System.err, dass das Programm sich verlangsamt. Dies ist, weil die gesamte Ausgabe auf dem Bildschirm in einer grafischen GUI-Umgebung wiedergegeben wird. Eigentlich ist es vielmehr das Betriebssystem als der Wrapper oder Ihre Anwendung, die viel Prozessorleistung konsumiert, aber das Endergebnis ist das Gleiche.

Um diese Wirkung deutlich zu reduzieren, nutzen Sie bitte, ein Log-Tool, welches die Ausgabe vielmehr in eine Datei statt in stdout schreibt. Dadurch wird die Ausgabe niemals zum Wrapper oder zur User-Konsole geschickt und es trägt zur Lastreduzierung bei.

Eine andere Option, die beinahe genauso gut ist, wie die Konsolen-Protokollierungsstufe des Wrappers zu konfigurieren, ist die, die wrapper.console.loglevel-Eigenschaft zu nutzen, so dass die Ausgabe nur in die Logdatei des Wrappers gesendet wird. Konsolenausgabe wird standardmäßig beim Ausführen als ein Windows Dienst deaktiviert. Dienst und Konsole werden nicht aktiviert.

Speicher

Stellen Sie bitte sicher, dass Ihr System über genügend physikalischen Speicher verfügt, damit die JVM ausgeführt werden kann, ohne dass irgendwelche Speicherauslagerung auf Festplatte (virtueller Speicher auf Festplatte) notwendig würde. Aufgrund der Art, wie Java mit Speicher umgeht, ist ein deutlicher Geschwindigkeitsvorteil üblich, einfach weil Java gezwungen wird, große Mengen seines Speichers zwischenzuspeichern, so wie es auch versuchte, eine Speicherbereinigung/"Garbage collection" auszuführen.

Dokumentation von Oracle

Eine andere gute Adresse, die man besuchen kann, ist, Leistungsdokumentation für den Java-HotSpot VM-Seite auf der Website von Oracle. Zusätzlich gibt es ein sehr informatives JDC-Tech-Tipp-Gespräch über "Garbage Collection"-Fragen.

Ich erhalte einen Fehler, dass der Wrapper nicht seine native Bibliothek laden kann.

Ein paar User haben bezüglich der Nachricht nachgefragt, die in ihrer wrapper.log-Datei auftaucht:

WrapperManager: ERROR - Unable to load the Wrapper's native library because none of the
WrapperManager:         following files:
WrapperManager:           wrapper-windows-x86-64.dll
WrapperManager:           wrapper.dll
WrapperManager:         could be located on the following java.library.path:
WrapperManager:           E:\myworkspace\tortoise\wrapper\wrapper_3.5.x\professional\bin\..\lib
WrapperManager:         Please see the documentation for the wrapper.java.library.path
WrapperManager:         configuration property.
Diese Nachricht wird angezeigt, weil die Java-Komponente des Wrappers nicht imstande war, ihre nativen Bibliotheken während der Initialisierung zu laden. Wenn Sie in Ihre wrapper.conf-Datei sehen, werden Sie eine Eigenschaft sehen, wrapper.java.library.path. Diese Eigenschaft wird genutzt, um das Verzeichnis zu spezifizieren, in das der Wrapper nachsehen wird, um seine native Bibliothek zu finden (Windows: wrapper.dll, Linux/UNIX: libwrapper.so). Sie sollten die Bibliotheksdatei in dem spezifizierten Verzeichnis ablegen oder die Eigenschaft wechseln, um auf das Verzeichnis zu zeigen, wo sich die Bibliotheksdatei befindet.

Meine Anwendung startet nicht. Was kann ich tun, um das Problem einzugrenzen?

? Please check the English version for a more up to date version of this text.
Output describing the problem should be displayed in the console as well as the configured log file. Um eine mehr detaillierte Ausgabe zu bekommen, editieren Sie bitte die wrapper.conf-Datei und aktivieren Sie das Debugging durch das Auskommentieren der wrapper.debug-Eigenschaft. Dies wird eine sehr detaillierte Ausgabe für jeden Schritt im Prozess des Startens und Überwachens Ihrer Anwendung anzeigen.

Wenn Ihre Anwendung unter Nutzung des Wrappers abstürzt, aber ohne ihn funktioniert, dann ist es sehr wahrscheinlich, dass es ein Problem gibt bezüglichdessen, wie Sie Ihre wrapper.conf-Datei eingerichtet haben. Bitte werfen Sie einen genaueren Blick auf den Befehl in der Debug-Ausgabe, der genutzt wird, um Java zu starten. Es ist möglich, dass es einen Fehler im Classpath oder etwas Ähnliches gibt.

Ich erhalte keinerlei Ausgabe in meiner konfigurierten Log-Datei.

Es ist möglich, dass der Wrapper nicht in der Lage ist, den Speicherort der spezifizierten Wrapper-Konfigurationsdatei zu ermitteln, oder er ist nicht imstande, die konfigurierte Log-Datei aus bestimmten Gründen zu öffnen. In beiden Fällen wird der Wrapper die Ausgabe in eine Datei namens wrapper.log in dem gegenwärtigen Arbeitsverzeichnis loggen. Das gegenwärtige Arbeitsverzeichnis wird sehr wahrscheinlich das Verzeichnis sein, welches die Programmdatei enthält. Jedoch in einigen Fällen, wenn als Windows-Dienst ausgeführt, kann die wrapper.log-Datei auch in Ihrem Systemverzeichnis (WinNT\System32) untergebracht sein.

Meine Anwendung hängt beim Beenden.

Wenn Sie System.exit() in Ihrer Anwendung aufrufen, dann wird der Wrapper dies abfangen und dann versuchen, die Anwendung ordnungsgemäß zu beenden. Wenn während des Beenden-Prozesses, Ihre Anwendung noch einmal System.exit() aufruft, dann wird der Aufruf auf unbestimmte Zeit blockiert, was bewirkt, dass Ihre Anwendung hängt. Es gibt auch Probleme beim Aufruf der destroy()-Methode auf einem AWT-Frame oder Fenster von innerhalb eines Shutdown-Hook-Threads. Bitte werfen Sie einen Blick in die wrapper.disable_shutdown_hook-Eigenschaft in der Konfigurationsübersicht bezüglich Details dazu, wie dieses Problem vermieden werden kann.

Meine JVM hängt, wenn sie sich nach Erstellung eines Thread-Dumps beendet.

Das Problem ist, dass Sie womöglich die wrapper.java.command-Eigenschaft viel mehr in eine Batch-Datei einstellen möchten statt direkt in die java.exe-Datei. Wenn Sie einen Thread-Dump anfordern, wird das "BREAK" -Signal eher zum Prozess command.exe/shell gesendet als zum Java-Prozess. Es leitet dann das Signal an die JVM weiter, aber setzt auch eine interne Flag-Markierung, dass STRG-C gedrückt wurde. Wenn der Kindprozess, Java sich beendet, wird der User sofort gefragt, ob danach gewünscht wird, die Batch-Skript-Datei zu beenden oder fortzusetzen.

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager Debug: Sent a packet STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | Wrapper  | 2009/10/23 14:30:56 | Shutdown failed: Timed out waiting for the JVM to terminate.
ERROR  | Wrapper  | 2009/10/23 14:30:56 | JVM did not exit on request, terminated
STATUS | Wrapper  | 2009/10/23 14:30:57 | <-- Wrapper Stopped

Wenn eine zusätzliche Weiterbearbeitung bevor oder nachdem die JVM gestartet wurde, notwendig wird, hat die Java Service Wrapper Professional Edition die Fähigkeit, genau dies zu tun:Wrapper-Ereigniskonfiguration

Ich kann den API-Aufruf WrapperManager.requestThreadDump (Error 0x57)

nicht nutzen.

Dieses Problem ist ähnlich und verursacht durch den gleichen Grund wie der vorherig Erwähnte oben.

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)

Wenn eine zusätzliche Weiterbearbeitung bevor oder nachdem die JVM gestartet wurde, notwendig wird, hat die Java Service Wrapper Professional Edition die Fähigkeit, genau dies zu tun:Wrapper-Ereigniskonfiguration

JBoss 6.* gibt viele Fehler folgender Art aus "ERROR: Error installing to..."; das sind Fehler beim Starten, wenn sie mit dem Wrapper ausgeführt werden

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

JBoss mit Version 6 benutzt intern eine MBeanServer Factory, die auf org.jboss.system.server.jmx.MBeanServerBuilderImpl basiert ist, jedoch ist diese inkompatibel zu der voreingestellten JVM MBeanServerBuilder (javax.management.MBeanServerBuilder).

Es gibt 2 verfügbare Optionen, um dies zu lösen. Erste Option ist, die Wrapper MBeans zu deaktivieren davon, registriert zu werden. Für diese Option sehen Sie bitte in die Integrationsmethode 1. Die zweite Option ist die, der JVM zu sagen, die MBeanServer Factory zu nutzen, welche JBoss auch nutzt. Mehr Information bezüglich dies, kann auf der folgenden Seite gefunden werden JMX-Seite.

Der Wrapper meldet beim Starten einen Fehler/Warnung bezüglich seiner Signatur.

wrapper  | A signature was found in "C:\wrapper-windows-x86-32-3.5.7-pro\bin\wra
pper.exe", but checksum failed: (Errorcode: 0x800b010a) 
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   Signer Certificate:
wrapper  |     Serial Number: 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: Tanuki Software Ltd.
wrapper  |   TimeStamp Certificate:
wrapper  |     Serial Number: 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: COMODO Time Stamping Signer
wrapper  |     Date of TimeStamp : 2010/12/19 22:32
wrapper  | The Wrapper will shutdown!

Beginnend mit der Wrapper Version 3.5.7, nutzen die Wrapper-Programmdateien (z.B. wrapper.exe, wrapperW.exe und wrapper.dll) von allen Wrapper-Editionen (Community, Standard, Professional) nutzen Codesigning, um die Dateiherkunft, dass sie von Tanuki Software stammt, zu überprüfen. Wenn irgendein Problem erkannt wurde, wird der Wrapper sich beenden.

Beginnend mit der Wrapper-Version 3.5.28, wird der Wrapper mit einem SHA-2-Zertifikat signiert, welche höhere Sicherheit als der vorherig genutzte SHA-1-Algorithmus ermöglicht.Die Entscheidung, das Zertifikat zu ändern, wurde in Compliance mit Microsofts SHA-1 deprecation plan gemacht, der erklärt, dass Windows 7 und aktueller SHA-1 nach dem 1.Januar 2016 nicht mehr unterstützen.

Der oben genannte Fehler tritt auf, wenn die Zertifikate, die von unserem Gegenzeichner 'Comodo' zur Verfügung gestellt werden, nicht korrekt installiert wurden.

Die Zertifikate sollten in einem store installiert werden, welcher von dem Konto unter den der Wrapper läuft, erreichbar ist. Wenn der Wrapper als eine Konsolenanwendung ausgeführt wird, mag dies der aktuelle User sein. Wenn als Dienst ausgeführt, sollte er von dem genutzten Dienstkonto erreichbar sein. Eine Alternative zu diesem ist es, das Zertifikat auf der lokalen Maschine zu installieren, so dass es in beiden Modi verfügbar ist.

Die installierten Zertifikate können von dem Windows Zertifikatmanager certmgr.msc (für den aktuellen User) oder von mmc (für jeden beliebigen User)überprüft werden.

Um die Zertifikate von einem spezifischen Konto zu verwalten, starten Sie launch 'mmc' vom Windows Ausführen-Suchfeld. Im Dateimenü klicken Sie auf 'Add/Remove Snap-in' und doppelklicken Sie dann auf 'Certificates'. Sie können dann wählen zwischen entweder Zertifikate des aktuellen Users, eines Dienstkontos oder des Computerkontos verwalten. Im Fall eines Dienstkontos wird eine Liste erscheinen mit allen auf dem Computer installierten Diensten. Sie sollten den Namen auswählen, der genutzt wird, wenn der Wrapper als ein Dienst installiert wird.

Nutzen von 'mmc' oder 'certmgr.msc', bitte bestätigen Sie die Zertifikatsinstallation:

Wenn diese Zertifikate nicht vorhanden oder veraltet sind, können sie von der Comodo-Website heruntergeladen werden.

? Please check the English version for a more up to date version of this text.

Um Zertifikate für den aktuellen User oder den lokalen Computer zu installieren, können Sie einfach die .crt-Datei ausführen und die folgenden Installationsschritte folgen. Um sie zu einem Dienstuser zu importieren, benutzen Sie bitte 'mmc', fügen das Snap-In, wie oben beschrieben, hinzu und im Menü klicken Sie auf 'Action > All tasks > Import' (Wählen Sie die Option "Automatically select the certificate store based on the type of certificate").

Wenn der Fehler immer noch auftritt, kann dies bedeuten, dass die lokalen Sicherheitsrichtlinien des Servers zu streng sind, um die Überprüfung der Zertifikate zu erlauben. Diese Einstellungen können in der lokalen Sicherheitsrichtlinie des Servers gefunden werden. Starten Sie bitte 'secpol.msc' vom Windows Ausführen-Suchfeld, klicken Sie auf "Public Key Policies", dann auf "Certificate Path Validation Settings". Stellen Sie bitte sicher, dass auf der Registerkarte 'Stores' "Third-Party Root CAs and Enterprise Root CAs" markiert ist, wenn die Richtlinieneinstellungen definiert wurden. Wenn dies so nicht aktiv gesetzt ist/kann, wäre eine andere Option, das "UTN-USERFirst-Object Certificate" von dem "Third Party Root CA"-Verzeichnis in das "Trusted Root Certificate Authorities"-Verzeichnis zu verschieben.

In der Wrapper-Version 3.5.8, wird sich der Wrapper nur beenden, wenn der Grund, dass die Signatur nicht überprüft wurde, direkt vom Wrapper verursacht wurde, und nicht durch den Gegenzeichner.

In der Wrapper-Version 3.5.7 gab es einen Bug, der möglicherweise eine Zugriffsverletzung verursachte, wenn die Signaturüberprüfung fehlschlug und der Wrapper versuchte, einen Fehler anzuzeigen.

? Please check the English version for a more up to date version of this text.

Schließlich sollte berücksichtigt werden, dass Windows XP SP2 und älter, sowie auch Windows Server 2003, SHA-2 und das neue Zertifikat auf diesen Plattformen nicht verwendet werden. Die Programmdateien, die für Windows Itanium zur Verfügung gestellt werden, werden nicht mehr signiert.

Warum versucht der Wrapper, auf den externen Comodo-Server zuzugreifen.

Der Wrapper selbst versucht nicht, auf den Comodo- oder andere Server zuzugreifen, aber beginnend mit der Wrapper-Version 3.5.7 werden die Programmdateien mit einem Comodo-Zertifikat signiert. Dies ist wichtig, um das Betriebssystem darin zu unterstützen, zu überprüfen, dass die Wrapper-Programmdateien wirklich von Tanuki Software stammen.

Wenn Windows versucht, eine signierte Programmdatei zu starten, wird es zuerst die Programmdatei überprüfen, um sicherzustellen, dass diese mit der Signatur übereinstimmt, um sich zu vergewissern, dass die Programmdatei nicht manipuliert wurde. Normalerweise müsste das Comodo-Zertifikat überprüfen, dass die Programmdatei auf einer Windows-Maschine existiert, aber in einigen Fällen, muss das Betriebssystem, sich mit dem Internet verbinden und diese von einem bekannten Ort herunterladen. Die Verbindung erfolgt, wenn der Wrapper aufgerufen wird, aber bevor er wirklich gestartet wird. Es kann jedoch den Anschein haben, als ob der Wrapper die Verbindung herstellt. Wir bekamen Mitteilungen von folgenden Servern, dass auf diese Art auf sie zugegriffen wurde : ocsp.comodoca.com, a125-56.204-123.deploy.akamaitechnologies.com (Der IP-Anteil der akamai-Server variiert je nach Anfrage)

Wenn dies irgendein Problem mit Kunden verursachen würde, dann wäre die eine Option für Standard und Professional Editionen, Ihre Wrapper-Programmdatei anzupassen, da dieser Prozess die Signatur entfernt. Dies wird jedoch natürlich auch die Fähigkeit des Betriebssystems, die Echtheit der Programmdatei zu überprüfen, entfernen.

Ich kann nur -N- Dienste auf Windows ausführen.

Der Wrapper selbst legt keinerlei Beschränkungen auf bezüglich der Zahl der Wrapper-Instanzen, die unter Windows zur gleichen Zeit ausgeführt werden können, aber beide, der Wrapper und insbesondere Java verbraucht diverse Ressourcen, die Beschränkungen dbzgl. auferlegen können, wie viele Instanzen auf einem vorhandenen System ausgeführt werden können. Die Ressource, die am häufigsten Probleme verursachen kann, ist der Desktop Heap. Sehen Sie bitte auf der Seite Solving Desktop Heap Problems für mehr Information.

Old issues

Ich erhalte einen Fehler darüber, dass das Schreiben einer PID-Datei beim Starten des Wrappers nicht durchgeführt werden kann.

Beginnend mit der Wrapper-Version 3.0.5, wurde die wrapper.pidfile-Eigenschaft auf der Windows-Plattform implementiert. Vorherige Versionen des Wrappers ignorierten diese Eigenschaft bei Ausführung unter Windows. Wenn jedoch die wrapper.conf-Datei, die Sie nutzen, unter Nutzung einer der Wrapper-Versionen vor Version 3.0.0, erstellt wurde, dann kann es sein, dass Sie diese Eigenschaft als "Verweigerung/Holdout" definiert werden, als Sie die Datei vom Beispiel wrapper.conf kopierten. Dies wird zu einem Fehler wie folgt führen:

ERROR: Could not write pid file /var/run/testwrapper.pid: The
system cannot find the path specified. (0x3)

Um diesen zu lösen, editieren Sie einfach Ihre wrapper.conf-Datei und entfernen die wrapper.pidfile-Eigenschaft.

Meine JVM-Version 1.2.x stürzt ab, wenn ich meine Anwendung mit dem Wrapper ausführe.

Bitte sehen Sie die Liste der unterstützten JVMs (Java Virtual Machines). Java Service Wrapper Version 3.4.x oder aktueller unterstützt JVM-Version 1.2.x nicht länger.

Die meisten der Features des Wrappers vor der Version 3.4.x funktionieren mit der Version 1.2.x der JVMs. Jedoch wurde die freigegebene Version des Wrappers unter Nutzung einer 1.4.x-Version von Java erstellt. 1.2.x-Version der JVM haben Probleme mit der erstellten Jar und werden mit JNI-Fehlern auf sehr niedriger Ebene abstürzen. Dies scheint ein Bug in den JVM 1.4.x-Versionen des Compilers zu sein, da dies sogar dann auftritt, wenn das JVM-Version 1.1-Target beim Kompilieren der Klassen spezifiziert wurde.

Hier ist ein Beispiel von aufgetretenen Fehlern:

A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has occurred in :
  'org/tanukisoftware/wrapper/WrapperManager.stopCommon (II)V': Interpreting method.
  Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cgi

Ich erhalte Hilfe von mehreren Leuten, um in der Lage zu sein, die Freigaben für alle die verschiedenen unterstützten Plattformen zu erhalten und es ist nicht wirklich möglich, jeden zu zwingen, alte JDKs zu nutzen, um Wrapper-Distributionen zu erstellen.

Wenn Sie bei Verwendung von JVMs 1.2.x-Version mit dem Wrapper mit Absturzproblemen konfrontiert sind, versuchen Sie bitte, eine Quellcodedistribution herunterzuladen und die wrapper.jar-Datei unter Nutzung der JDK 1.2.x-Version zu erstellen. Dies wird das Problem lösen.

Wenn Sie so ein Problem antreffen, senden Sie bitte eine Mitteilung an die Wrapper-User-Mailingliste. Es ist nicht sicher, wie viele User noch die 1.2.x-JVM nutzen; aber wenn es noch ziemlich üblich ist, kann die oben genannte Vorgehensweise überdacht und geprüft werden, was vonnöten wäre, um Freigaben unter Nutzung einer älteren JVM zu erstellen.

Meine JVM wird manchmal, wenn das System unter großer Last ist, neu gestartet.

Weil der Java Service Wrapper einen Pinging-Mechanismus benutzt, um den Zustand der JVM zu prüfen, ist es möglich, dass der Wrapper denken wird, dass die JVM sich aufgehängt hat, auch dann, wenn es nicht der Fall ist, wenn ein anderer Prozess 100%-Prozessorleistung for longer than 30 seconds. Dies wird zu einem Eintrag wie den Folgenden in Ihrer Logdatei führen, und dazu, dass die JVM neu gestartet wird:

jvm 1    | 2001/12/01 12:23:23 | start()
wrapper  | 2001/12/01 12:23:44 | Startup failed: Timed out waiting for signal from JVM.
wrapper  | 2001/12/01 12:23:44 | JVM did not exit on request, terminated
wrapper  | 2001/12/01 12:23:49 | Launching a JVM...
jvm 2    | 2001/12/01 12:23:50 | Initializing...

Die Eigenschaft wrapper.ping.timeout=30 in conf/wrapper.log kann genutzt werden, um die Timeoutzeit zu erhöhen. Aber seien Sie sich bewusst, dass dies auch die Zeitdauer verlängern wird, während der Ihre Anwendung im Falle eines wirklichen Problems hängen wird.

Ich kann den Wrapper unter MacOS Mavericks nicht starten.

Bis zur Wrapper-Version 3.5.22, wenn Sie den Wrapper unter MacOS Mavericks starten, bekommen Sie einen Fehler angezeigt. Dies liegt daran, dass das Skript die 64-bit-Versionen der Programmdateien nicht nutzen kann.

Die Lösung zu diesem Problem ist es, die folgende Skriptdatei ausfindig zu machen und sie dann zum Editieren zu öffnen: src/bin/sh.script.in (Sie haben wahrscheinlich diese Datei umbenannt).

Öffnen der Datei (src/bin/sh.script.in):
OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*\.[0-9]*\.[0-9]*'`
Bitte editieren Sie die Zeile wie folgt:
OS_VER=`sw_vers | grep 'ProductVersion:' | grep -o '[0-9]*\.[0-9]*\.[0-9]*\|[0-9]*\.[0-9]*'`