Jboss org.jgroups.protocols.pbcast.NAKACK numéro

Question

[org.jgroups.protocols.pbcast.NAKACK] (requester =, local_addr =) message :: port introuvable dans la table de retransmission de: port: (size = xxxx , missing = x, stability le plus élevé = xxxxx)]

Answer 1

NAKACK (ou son cousin plus récent, NAKACK2) fournissent une transmission fiable des messages au cluster. Pour ce faire, chaque message reçoit un numéro de séquence (seqno) et les récepteurs livrent le message à l'application dans un ordre différent.

Chaque membre de la grappe dispose d'une table de tous les autres membres et de leurs messages (conceptuellement une liste). Lorsque le membre P envoie les messages P21, P22 et P23, un récepteur R consulte d'abord la liste de messages de R, puis ajoute P21-P23 à la liste.

Cependant, dans votre cas, la liste de R n'a pas été trouvée. Cela signifie que R n'était plus un membre de cluster. Par exemple, si nous avons un cluster {P, Q, R, T} et que le membre R quitte ou est exclu parce qu'il était suspecté (par exemple, nous n'avons pas reçu de pulsation pendant un certain temps), les messages P21-23 sera abandonné par n'importe quel récepteur. Ceci est dû au fait que JGroups autorise uniquement les membres de cluster à envoyer et à recevoir des messages.

Comment un membre peut-il être exclu?

Ceci est probablement effectué par l'un des protocoles de détection d'échec (par exemple FD_ALL ou FD).

Une autre possibilité est que vos pools d'unités d'exécution étaient obstrués et que les messages d'alerte de détection d'échec ont été supprimés, ce qui a provoqué de fausses suspicions. De plus, de longues pauses GC peuvent provoquer cela.

Corrections:

• Augmenter les délais d'attente dans FD_ALL ou FD. Le délai d'attente devrait être plus long que le plus long cycle du GC. Notez qu'il faudra maintenant plus de temps pour détecter les membres bloqués.
• Dimensionnez vos pools de threads, par ex. assurez-vous que le nombre maximal de threads est important et que la file d'attente est désactivée.

Notez que les faux soupçons peuvent arriver, mais MERGE3 devraient rememdy un cluster partagé plus tard.