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?

Ausgabe, die das Problem beschreiben, sollten in der Konsole wie auch in der konfigurierten Logdatei angezeigt werden. 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.

? Please check the English version for a more recent version of this text.

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

  • "AddTrust External CA Root" sollte unter "Trusted Root Certificate Authorities\Certificates" installiert werden

  • "COMODO RSA Certification Authority" und "COMODO RSA Code Signing" sollten unter "Intermediate Certification Authorities\Certificates" installiert werden. Bitte stellen Sie sicher, dass Ihre Signatur-Hash-Algorithmen mit der Version des Wrappers übereinstimmen, die Sie nutzen (sh384 oder sha-2 für Wrapper 3.5.28 und aktueller, und sha-1 für frühere Versionen). Dies kann durch Doppelklicken auf das Zertifikat Öffnen der 'Details'-Registerkarte überprüft werden. Sie können auch überprüfen, dass diese Zertifikate in dem Eigenschaftenfenster, welches vom Kontextmenü zugänglich ist, aktiviert sind.

  • "UTN-USERFirst-Object" sollte unter "Third Parties Root Certification Authorities\Certificates" installiert werden.

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

Um die Zertifikate für den aktuellen User oder den lokalen Computer zu installieren, können Sie einfach die .crt-Datei ausführen und den folgenden Installationsschritte folgen. Um sie zu einem Dienstuser zu importieren, benutzen Sie bitte 'mmc', fügen das Snap-In, wie oben beschrieben, hinzu. Wählen Sie dann einen beliebigen Speicherplatz (markiert mit einem Ordnersymbol) unterhalb dieses Snap-In auf der linken Seite, und im Menü klicken Sie auf "Aktion> Alle Aufgaben> Importieren" (Wählen Sie die Option "Den Zertifikatspeicher automatisch anhand des Zertifikatstyps auswählen").

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.

Seit Wrapper-Version 3.5.34 sind die Wrapper-Binärdateien doppelt mit SHA-1- und SHA-2-Hash-Algorithmen signiert, um eine stärkere Überprüfung auf Betriebssystemebene zu ermöglichen. Um Algorithmen und Zeitstempel zu überprüfen, klicken Sie mit der rechten Maustaste auf die Binärdateien und öffnen Sie das Fenster "Eigenschaften" des Kontextmenüs, dann wählen Sie die Registerkarte "Digitale Signaturen":

Beachten Sie, dass der SHA-256-Hash-Algorithmus nicht in alten Windows-Versionen angezeigt wird, in denen dieser Algorithmus nicht unterstützt wird. Microsoft veröffentlichte ein Update für Windows 7 und Windows Server 2008 R2, um die Unterstützung für SHA-2 hinzuzufügen. Wenn dieses Update vorhanden ist, können Sie den SHA-2-Hash überprüfen, andernfalls können Sie nur den SHA-1-Hash verifizieren. Neuere Windows-Versionen benötigen dieses Update nicht, da sie bereits SHA-256 unterstützen, wohingegen ältere Versionen (Windows XP, Vista, Windows Server 2008) nur SHA-1-Hashes überprüfen können.

Sie können bestätigen, dass eine digitale Signatur gültig ist, indem Sie in der Signaturliste darauf klicken:

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.

Wie kann ich neue Java 9-Optionen spezifizieren, für die Argumente erforderlich sind (z. B. für die Angabe von Modulen)?

Java 9 führt mehrere Optionen ein (z.B. --module-path oder --add-modules), die mit einem Argument angegeben werden müssen. Normalerweise wird das Argument durch ein Leerzeichen vom Optionsnamen getrennt, aber jeder Leerraum innerhalb der Werte der wrapper.java.additional.<n> Eigenschaften wird als Teil des Argumentwerts und nicht als Trennzeichen interpretiert. Eine Lösung besteht darin, den Optionsnamen und das Argument durch ein Gleichheitszeichen (=) anstelle eines Leerzeichens zu trennen. 

wrapper.java.additional.1=--add-modules=MODULE1,MODULE2

Beachten Sie, dass dies nur mit langen Optionen funktioniert (solche, die mit '--' beginnen) und nicht mit ihren kurzen Aliasen. Zum Beispiel ist '-p=<PATH>' nicht erlaubt ('-p' ist ein Alias ??von '--module-path').

Eine andere Lösung, bei der Sie sowohl Leerzeichen als auch kurze Aliase verwenden können, ist die Verwendung der Umgebungsvariable JDK_JAVA_OPTIONS. Der Inhalt dieser Variablen wird von der JVM den Optionen der Befehlszeile hinzugefügt. Sie können es mithilfe der folgenden Syntax aus der Wrapper-Konfigurationsdatei heraus festlegen: 

set.JDK_JAVA_OPTIONS=--add-modules MODULE1,MODULE2

Beachten Sie jedoch, dass Sie den Inhalt von JDK_JAVA_OPTIONS nicht visualisieren können, wenn Sie die Java-Befehlszeile wrapper.java.command.loglevel Eigenschaft) anzeigen, da diese von der JVM nur beim Start geparst wird.

Weitere Informationen zu den Long-Optionen und der Variablen JDK_JAVA_OPTIONS finden Sie auf der Website von Oracle.

? Please check the English version for a more recent version of this text.

How can I solve slow startup times on Linux due to random seed generator?

Java applications that make calls to java.util.Random.nextLong() or other random methods can be very very slow the first time they are called. This is caused by a lack of entropy on the system. The call will block until such entropy has build up enough to return a good number. Unfortunately on startup when nothing else is happening, this can take a very long time, during which your application will appear to be frozen.

About the only way to detect whether or not this is happening is to issue a thread dump request while it is waiting. If this is the cause, you can see it easily.

Once this has been identified as the problem, a solution that we have found is to add the following property to your configuration. This changes the way Java generates random data to a method that is always fast. We make no claims on how this affects security so please investigate this and let us know if you have a better solution. Be sure to use a number which does not overlap with your existing configuration: 

# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

This is a platform specific solution. If you need to have a platform independent configuration then please create a second wrapper-linux.conf configuration file: 

#encoding=UTF-8
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom

Then include that based on platform from your main configuration file. In such cases, I add a comment in the main configuration to make sure the numbered property is not reused by mistake. 

#encoding=UTF-8
#include ../conf/wrapper-%WRAPPER_OS%.conf
...
# Solve slow random initialization on Linux
#wrapper.java.additional.20= # Reserved for use in wrapper-linux.conf

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/App.sh.in (Sie haben wahrscheinlich diese Datei umbenannt).

Öffnen der Datei (src/bin/App.sh.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]*'`