wrapper.backend.socket.bind.timeout
Compatibilité :3.6.3
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Le Wrapper utilise une connexion backend (socket ou pipe) pour communiquer avec la JVM qu'il surveille. Cette connexion est établie, généralement de manière quasi instantanée, au démarrage avant que le Wrapper ne lance une JVM.

Pour les connexions socket, une étape supplémentaire consiste à effectuer un binding sur l'adresse de loopback et un port spécifique. En général, l'adresse de loopback est disponible, et le Wrapper sélectionne le premier port disponible dans la plage configurée. Cependant, dans certaines configurations, il a été observé que les adresses IPv4 et/ou IPv6 peuvent temporairement se détacher de leur interface réseau. Cela peut se produire, par exemple, lorsque l'interface de loopback est gérée par systemd-networkd. Lorsque systemd-networkd applique des modifications de configuration, il démonte et reconfigure brièvement les interfaces, ce qui entraîne généralement quelques millisecondes d'indisponibilité pendant lesquelles les adresses de loopback ne sont pas disponibles.

À partir de la version 3.6.3 du Wrapper, le Wrapper inclut un mécanisme de nouvelle tentative pour les situations où l'adresse n'est pas disponible lors du binding. La propriété wrapper.backend.socket.bind.timeout configure la durée maximale, en secondes, de ce mécanisme de nouvelle tentative. Si le délai expire, le Wrapper cessera ses tentatives et s'arrêtera.

Sous Unix, la valeur par défaut est de 5 secondes.

Sous Windows, comme aucun problème d'indisponibilité similaire n'a été observé, la valeur par défaut est de 0 seconde, ce qui désactive le mécanisme de nouvelle tentative. Cependant, cette valeur peut être modifiée si nécessaire.

NOTE

Si wrapper.backend.type est défini sur AUTO ou SOCKET et que l'adresse de loopback n'est pas disponible pour SOCKET_IPv4 ou SOCKET_IPv6, le Wrapper ne restera pas bloqué sur ce type. Au lieu de cela, il tentera immédiatement de créer une connexion avec le type suivant dans l'ordre de repli : SOCKET_IPv6, puis SOCKET_IPv4, puis PIPE (le cas échéant).

Si aucun type ne réussit dans le cycle en cours, le mécanisme de nouvelle tentative lancera un nouveau cycle, et ce jusqu'à ce qu'un type approprié soit trouvé ou que le délai expire. Cela permet au Wrapper d'être plus réactif au démarrage.

Il est également possible de définir wrapper.backend.type sur un type spécifique et de désactiver ce mécanisme de repli.

Voici ce qui peut être observé dans les journaux lorsque le binding sur les adresses de loopback IPv4 et IPv6 échoue et que wrapper.backend.type est défini sur SOCKET. 

INFO   | 2025/08/01 18:34:40.976 | wrapperp | Could not assign a name to the socket. Waiting 5 seconds...
INFO   | 2025/08/01 18:34:41.082 | wrapperp | Backend server started with SOCKET_IPv4.

Référence : Port
  • wrapper.backend.type (3.5.8)

    Configure la communication entre le processus du Wrapper et la classe s'exécutant dans la JVM.

  • wrapper.port (1.0.0)

    Configure le port que le Wrapper utilisera pour se connecter à la JVM.

  • wrapper.port.max (3.2.0)

    Spécifie la limite supérieure de la plage de ports que le Wrapper utilisera pour se connecter à la JVM.

  • wrapper.port.min (3.2.0)

    Spécifie la limite inférieure de la plage de ports que le Wrapper utilisera pour se connecter à la JVM.

  • wrapper.jvm.port (3.2.0)

    Configure le port que la JVM utilisera pour se reconnecter au Wrapper.

  • wrapper.jvm.port.max (3.2.0)

    Spécifie la limite supérieure de la plage de ports que la JVM utilisera pour se reconnecter au Wrapper.

  • wrapper.jvm.port.min (3.2.0)

    Spécifie la limite inférieure de la plage de ports que la JVM utilisera pour se reconnecter au Wrapper.