Mon programme ne s'exécute pas aussi rapidement que je le souhaiterais.
En général, une application devrait s'exécuter aussi rapidement sous le Wrapper que lorsqu'elle s'exécute de manière autonome.
Voici quelques pistes à examiner.
Sortie console
Sur certaines plates-formes, notamment Windows, l'envoi de grandes quantités de texte vers
System.out ou System.err
ralentit le programme.
Cela s'explique par le fait que toute cette sortie est affichée à l'écran dans un environnement graphique.
C'est en réalité le système d'exploitation qui consomme le processeur, et non le Wrapper ou votre application,
mais le résultat final est le même.
Pour réduire considérablement cet effet, utilisez un outil de journalisation qui écrit dans un fichier plutôt que vers stdout.
Ainsi, la sortie n'est jamais envoyée au Wrapper ni à la console utilisateur, ce qui allège la charge.
Une autre option, presque aussi efficace, consiste à configurer le niveau de journalisation de la console du Wrapper,
à l'aide de la propriété wrapper.console.loglevel,
de sorte que la sortie soit uniquement envoyée vers le fichier journal du Wrapper.
La sortie console est désactivée par défaut lors de l'exécution en tant que service Windows
et lorsque la console n'a pas été activée.
Mémoire
Assurez-vous que votre système dispose de suffisamment de mémoire physique pour que la JVM s'exécute
sans recourir à l'échange disque (mémoire virtuelle sur disque dur).
En raison de la façon dont Java gère la mémoire, un ralentissement très important est fréquent simplement
parce que Java est forcé de paginer de grandes quantités de sa mémoire
lorsqu'il tente d'effectuer le « ramasse-miettes » (garbage collection).
J'obtiens une erreur indiquant que le Wrapper ne peut pas charger sa bibliothèque native.
Quelques utilisateurs ont signalé l'apparition du message suivant
dans leur fichier wrapper.log :
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.
Ce message s'affiche parce que le composant Java du Wrapper n'a pas pu charger ses
bibliothèques natives lors de l'initialisation.
Si vous consultez votre fichier wrapper.conf,
vous y trouverez une propriété, wrapper.java.library.path.
Cette propriété sert à indiquer le répertoire dans lequel le Wrapper recherchera sa bibliothèque native
(Windows : wrapper.dll, Linux/UNIX : libwrapper.so).
Vous devez placer le fichier de bibliothèque dans le répertoire spécifié
ou modifier la propriété pour qu'elle pointe vers le répertoire où se trouve la bibliothèque.
Si vous utilisez le Delta Pack, assurez-vous que la bibliothèque correspondant à votre plate-forme se trouve dans le répertoire spécifié.
Mon application ne démarre pas. Que puis-je faire pour isoler le problème ?
Une description du problème devrait s'afficher dans la console,
ainsi que dans le fichier journal configuré.
Pour obtenir une sortie plus détaillée,
modifiez votre fichier wrapper.conf et
activez le débogage en décommentant la propriété wrapper.debug.
Cela affichera une sortie très détaillée à chaque étape du processus de lancement et de surveillance de votre application.
Si votre application fonctionne sans le Wrapper, mais échoue avec le Wrapper,
il est très probable qu'il y ait un problème dans la configuration de votre fichier wrapper.conf.
Examinez attentivement la commande utilisée pour lancer Java dans la sortie de débogage.
Il est possible qu'il y ait une erreur dans le classpath ou ailleurs.
Je n'obtiens aucune sortie dans le fichier journal configuré.
Il est possible que le Wrapper ne parvienne pas à localiser le fichier de configuration du Wrapper spécifié,
ou qu'il ne puisse pas ouvrir le fichier journal configuré pour une raison quelconque.
Dans les deux cas, le Wrapper consignera la sortie dans
un fichier nommé wrapper.log
dans le répertoire de travail actuel.
Le répertoire de travail actuel sera très probablement le répertoire contenant le binaire.
Cependant, dans certains cas, lors de l'exécution en tant que service Windows, le
fichier wrapper.log
peut être placé dans votre répertoire système (WinNT\System32).
Mon application se bloque pendant l'arrêt.
Si vous appelez System.exit() dans votre application,
le Wrapper interceptera cet appel et tentera d'arrêter l'application proprement.
Si, pendant le processus d'arrêt, votre application appelle à nouveau System.exit(),
l'appel se bloquera indéfiniment, ce qui entraînera le blocage de votre application.
Il existe également des problèmes liés à l'appel de la méthode destroy()
sur un cadre ou une fenêtre AWT depuis un thread de hook d'arrêt (Shutdown Hook).
Consultez la
propriété wrapper.disable_shutdown_hook
dans la Vue d'ensemble de la configuration pour plus de détails sur la façon d'éviter ce problème.
Ma JVM se bloque à l'arrêt après un vidage de threads.
Le problème est que vous avez peut-être défini la
propriété wrapper.java.command
sur un fichier batch plutôt que directement sur java.exe.
Lors de la demande d'un vidage de threads, le signal « BREAK » est envoyé au
processus command.exe/shell plutôt qu'au processus Java.
Celui-ci transmet ensuite le signal à la JVM, mais définit également un indicateur interne indiquant que CTRL-C a été pressé.
Avant que le processus Java ne se termine, il demande à l'utilisateur s'il souhaite arrêter ou poursuivre le script batch.
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
Si vous devez effectuer un traitement supplémentaire avant ou après
le lancement de la JVM, l'édition Professional de Java Service Wrapper permet de le faire : Configuration des événements du Wrapper.
Je ne peux pas utiliser l'appel API WrapperManager.requestThreadDump (erreur 0x57)
Ce problème est similaire et a la même cause que celui mentionné ci-dessus.
INFO | jvm 1 | 2009/10/23 14:35:48 | WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)
Si vous devez effectuer un traitement supplémentaire avant ou après
le lancement de la JVM, l'édition Professional de Java Service Wrapper permet de le faire : Configuration des événements du Wrapper
JBoss 6.* affiche de nombreuses erreurs « ERROR: Error installing to... » au démarrage lorsqu'il s'exécute avec le Wrapper
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 version 6 utilise en interne une fabrique MBeanServer basée sur
org.jboss.system.server.jmx.MBeanServerBuilderImpl,
toutefois, celle-ci est incompatible avec le
MBeanServerBuilder par défaut de la JVM (javax.management.MBeanServerBuilder).
Deux options sont disponibles pour résoudre ce problème.
La première consiste à empêcher l'enregistrement des MBeans du Wrapper.
Pour cette option, consultez la Méthode d'intégration 1.
La seconde consiste à indiquer à la JVM d'utiliser la fabrique MBeanServer utilisée par JBoss.
Plus d'informations à ce sujet sont disponibles sur la page JMX.
Le Wrapper signale une erreur/avertissement concernant sa signature au démarrage.
wrapper | A signature was found in "C:\wrapper-windows-x86-64-3.5.54-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 bf de 76 64 f1 1a d5 f3 dd af a7 e4 d7 c7 0f 5e
wrapper | Issuer Name: Sectigo RSA Code Signing CA
wrapper | Subject Name: Tanuki Software Ltd.
wrapper | TimeStamp Certificate:
wrapper | Serial Number:
wrapper | 39 4c 25 e1 7c a0 6d 27 a8 65 e2 3b d9 1d 22 d4
wrapper | Issuer Name: Sectigo RSA Time Stamping CA
wrapper | Subject Name: Sectigo RSA Time Stamping Signer #4
wrapper | Date of TimeStamp: 2023/05/12 06:24:23
wrapper | The Wrapper will shutdown!
À partir de la version 3.5.7 du Wrapper, les binaires Windows (c'est-à-dire
wrapper.exe, wrapperW.exe et wrapper.dll)
de toutes les éditions du Wrapper (Community, Standard, Professional) sont signés numériquement afin de vérifier qu'ils proviennent de Tanuki Software.
À partir de la version 3.5.28 du Wrapper, le Wrapper est signé avec un certificat SHA-2 qui offre une sécurité plus élevée que l'algorithme SHA-1 utilisé auparavant. La décision de changer de certificat a été prise conformément au plan de dépréciation de SHA-1 de Microsoft, qui indique que Windows 7 et versions ultérieures ne prendront plus en charge SHA-1 après le 1er janvier 2016.
L'erreur ci-dessus se produit lorsque les certificats fournis par notre contre-signataire « Sectigo » ne sont pas correctement installés.
Les certificats doivent être installés dans un magasin accessible depuis le compte sous lequel le Wrapper s'exécute. Lorsque le Wrapper s'exécute en tant qu'application console, il peut s'agir de l'utilisateur actuel. Lorsqu'il s'exécute en tant que service, le magasin doit être accessible depuis le compte de service utilisé. Une alternative consiste à installer le certificat sur l'ordinateur local afin qu'il soit accessible dans les deux modes.
Les certificats installés peuvent être consultés depuis le Gestionnaire de certificats Windows certmgr.msc (pour l'utilisateur actuel) ou mmc (pour n'importe quel utilisateur).
Pour gérer les certificats d'un compte spécifique, lancez « mmc » depuis la zone de recherche Exécuter de Windows. Dans le menu Fichier, cliquez sur « Ajouter/Supprimer un composant logiciel enfichable » et double-cliquez sur « Certificats ». Vous pouvez alors choisir de gérer les certificats de l'utilisateur actuel, d'un compte de service ou du compte d'ordinateur. Dans le cas du compte de service, une liste de tous les services installés sur l'ordinateur s'affiche. Sélectionnez le compte qui a été utilisé lors de l'installation du Wrapper en tant que service.
Pour télécharger les certificats, veuillez ouvrir la page suivante :
Les liens vers les certificats se trouvent dans la section « Code Signing - Intermediate ». Veuillez utiliser les liens « Standard ».
Pour le Wrapper version 3.5.46 et ultérieures, vous pouvez utiliser les liens « Standard » sous « For Code Signing Certificates, issued on or after June 1, 2021 ».
Les liens « Sectigo Public Code Signing CA R36 » et « SectigoPublicCodeSigningRootR46_AAA [ Cross Signed ] » fonctionnent tous deux avec le Wrapper. Pour une explication détaillée de ce que sont les certificats racine, intermédiaires ou contre-signés, veuillez consulter la page suivante du site Web de Sectigo :
Pour installer les certificats pour l'utilisateur actuel ou l'ordinateur local, vous pouvez simplement exécuter le fichier .crt et suivre les étapes d'installation.
Pour les importer vers un utilisateur de service, utilisez « mmc », ajoutez le composant logiciel enfichable comme décrit ci-dessus, sélectionnez n'importe quel magasin (marqué d'une icône de dossier) sous ce composant dans le panneau de gauche, puis dans le menu cliquez sur « Action > Toutes les tâches > Importer » (choisissez l'option « Sélectionner automatiquement le magasin de certificats en fonction du type de certificat »).
Si l'erreur s'affiche toujours, cela peut signifier que la Stratégie de sécurité locale du serveur est trop stricte pour permettre la vérification des certificats. Ces paramètres se trouvent dans la Stratégie de sécurité locale du serveur.
Lancez « secpol.msc » depuis la zone de recherche Exécuter de Windows, cliquez sur "Public Key Policies", puis "Certificate Path Validation Settings". Sous l'onglet « Magasins », assurez-vous que "Third-Party Root CAs and Enterprise Root CAs" est coché si des paramètres de stratégie sont définis.
Si cela n'est pas / ne peut pas être activé, une autre option consisterait à déplacer le "UTN-USERFirst-Object Certificate"
du dossier "Third Party Root CA" vers le dossier "Trusted Root Certificate Authorities".
Depuis la version 3.5.34 du Wrapper, les binaires du Wrapper sont doublement signés
avec les algorithmes de hachage SHA-1 et SHA-2 afin de permettre une vérification plus robuste au niveau du système d'exploitation.
Pour vérifier les algorithmes et les horodatages, cliquez avec le bouton droit sur les binaires et ouvrez la fenêtre « Propriétés » depuis le
menu contextuel, puis sélectionnez l'onglet « Signatures numériques » :
Notez que l'algorithme de hachage SHA-256 n'apparaîtra pas sur les anciennes versions de Windows où cet algorithme n'est pas pris en charge.
Microsoft a publié une mise à jour
pour Windows 7 et Windows Server 2008 R2 afin d'ajouter la prise en charge de SHA-2.
Si cette mise à jour est présente, vous pourrez vérifier le hachage SHA-2, sinon vous ne pourrez vérifier que le hachage SHA-1.
Les versions plus récentes de Windows n'ont pas besoin de cette mise à jour, car elles prennent déjà en charge SHA-256,
tandis que les versions plus anciennes (Windows XP, Vista, Windows Server 2008) ne peuvent vérifier que les hachages SHA-1.
Vous pouvez confirmer qu'une signature numérique est valide en cliquant dessus dans la liste des signatures :
Pourquoi le Wrapper tente-t-il d'accéder à un serveur Sectigo externe ?
Le Wrapper lui-même n'essaie pas réellement d'accéder aux serveurs Sectigo ou à d'autres serveurs, mais à partir de la version 3.5.7 du Wrapper,
les binaires sont désormais signés avec un certificat Sectigo.
Cela est important pour aider le système d'exploitation à vérifier que les binaires du Wrapper proviennent bien de Tanuki Software.
Lorsque Windows tente de lancer un binaire signé, il vérifie d'abord le binaire pour s'assurer qu'il correspond à la signature, afin de garantir que le binaire n'a pas été altéré.
Normalement, le certificat Sectigo nécessaire pour vérifier le binaire est présent sur une machine Windows, mais dans certains cas, le système d'exploitation doit se connecter à Internet et le télécharger depuis un emplacement connu.
La connexion a lieu pendant le lancement du Wrapper, mais avant qu'il ne soit réellement démarré.
Il peut toutefois sembler que ce soit le Wrapper qui établit la connexion.
Nous avons reçu des rapports indiquant que les serveurs suivants étaient contactés de cette manière : ocsp.comodoca.com, a125-56.204-123.deploy.akamaitechnologies.com (la partie IP des serveurs Akamai varie selon la requête).
Si cela préoccupe certains clients, une option sur les éditions Standard et Professional consiste à personnaliser votre binaire Wrapper, car ce processus supprime la signature.
Cela supprimera toutefois, bien entendu, la capacité du système d'exploitation à vérifier l'authenticité du binaire.
Je ne peux exécuter que -N- services sous Windows.
Le Wrapper lui-même n'impose aucune restriction sur le nombre d'instances du Wrapper
pouvant s'exécuter simultanément sous Windows, mais le Wrapper et surtout Java
consomment diverses ressources, ce qui peut limiter le nombre d'instances pouvant s'exécuter sur
un système donné. La ressource la plus courante à l'origine de problèmes est le tas du Bureau (Desktop Heap).
Consultez la page Résoudre les problèmes de tas du Bureau
pour plus d'informations.
Comment puis-je résoudre les temps de démarrage lents sous Linux dus au générateur de graine aléatoire ?
Les applications Java qui appellent java.util.Random.nextLong() ou d'autres méthodes aléatoires peuvent être très, très lentes lors du premier appel.
Cela est dû à un manque d'entropie sur le système. L'appel se bloquera jusqu'à ce que suffisamment d'entropie se soit accumulée pour renvoyer un bon nombre.
Malheureusement, au démarrage, lorsque rien d'autre ne se passe, cela peut prendre très longtemps, période pendant laquelle votre application semblera figée.
Pratiquement le seul moyen de détecter si cela se produit est d'émettre une demande de vidage de threads pendant l'attente.
Si c'est la cause, vous devriez pouvoir le constater facilement.
Une fois ce problème identifié, une solution que nous avons trouvée consiste à ajouter la propriété suivante à votre configuration.
Cela modifie la façon dont Java génère des données aléatoires pour utiliser une méthode toujours rapide.
Nous ne faisons aucune affirmation quant à l'impact sur la sécurité ; veuillez donc vous renseigner à ce sujet et nous indiquer si vous avez une meilleure solution.
Veillez à utiliser un numéro qui ne chevauche pas votre configuration existante :
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom
Il s'agit d'une solution spécifique à la plate-forme.
Si vous avez besoin d'une configuration indépendante de la plate-forme, veuillez créer un second fichier de configuration wrapper-linux.conf :
@encoding=UTF-8
# Solve slow random initialization on Linux
wrapper.java.additional.20=-Djava.security.egd=file:/dev/./urandom
Incluez ensuite ce fichier en fonction de la plate-forme depuis votre fichier de configuration principal.
Dans ce cas, nous suggérons d'ajouter un commentaire dans la configuration principale afin de vous assurer que la propriété numérotée n'est pas réutilisée par erreur.
@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
