Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

18.4.2. Détection des échecs côté-client

L'application du client envoie automatiquement des paquets de pings au serveur pour éviter que le client échoue. De la même manière, l'application du client considère que la connexion est vivante tant qu'elle reçoit des données du serveur.
Si le client ne reçoit pas de paquets de données du serveur pour une période de temps spécifiée par le paramètre client-failure-check-period, alors le client considère que la connexion a échoué. Ensuite, le client initie un basculement ou appelle les instances FailureListener.
Pour les clients JMS, « client-failure-check-period » est configuré à l'aide de l'attribut ClientFailureCheckPeriod sur l'instance HornetQConnectionFactory. Si vous déployez des instances d'usine de connexions JMS directement dans JNDI sur le serveur, vous pouvez spécifier le paramètre client-failure-check-period dans les fichiers de configuration de serveur standalone.xml et domain.xml.
La valeur par défaut de « client-failure-check-period » est de 3 000 millisecondes. Une valeur de-1 signifie que le client ne fermera jamais la connexion, si aucune donnée n'est reçue du serveur. La valeur de « client-failure-check-period » est beaucoup plus faible que le TTL de connexion afin que les clients puissent se reconnecter en cas d'un échec de transition.
Configuration de l'exécution de connections asynchrones

Par défaut, les paquets reçus sur le serveur sont exécutés sur le thread d'accès distant. Il est possible de libérer le thread de l'accès distant en procédant à des opérations asynchrones sur n'importe quel thread du pool de threads. Vous pouvez configurer une exécution de connexion asynchrone grâce au paramètre async-connection-execution-enabled dans les fichiers de configuration de serveur standalone.xml et domain.xml. La valeur par défaut de ce paramètre est « true ».

Note

Si vous traitez les opérations de façon asynchrone sur n'importe quel thread du pool de threads, cela va ajouter un petit temps de latence. Les opérations en cours d'exécution sont toujours gérées sur le thread d'accès distant pour des raisons de performance.