Problème avec Hazelcast/CONCURRENT_MAP_LOCK après le redémarrage du serveur

Nous utilisons Hazelcat 1.9.4.4 avec cluser de 6 serveurs Tomcat. Nous remis en marche notre cluster, fourmi est ici un fragment du journal:Problème avec Hazelcast/CONCURRENT_MAP_LOCK après le redémarrage du serveur

14-Jul-2012 03:25:41 com.hazelcast.nio.InSelector 
INFO: /10.152.41.105:5701 [cem-prod] 5701 accepted socket connection from /10.153.26.16:54604 
14-Jul-2012 03:25:47 com.hazelcast.cluster.ClusterManager 
INFO: /10.152.41.105:5701 [cem-prod] 

Members [6] { 
     Member [10.152.41.101:5701] 
     Member [10.164.101.143:5701] 
     Member [10.152.41.103:5701] 
     Member [10.152.41.105:5701] this 
     Member [10.153.26.15:5701] 
     Member [10.153.26.16:5701] 
}

On peut voir que 10.153.26.16 est connecté au cluster, mais après plus tard dans le journal il y a:

14-Jul-2012 03:28:50 com.hazelcast.impl.ConcurrentMapManager 
INFO: /10.152.41.105:5701 [cem-prod] ======= 47: CONCURRENT_MAP_LOCK ======== 
     thisAddress= Address[10.152.41.105:5701], target= Address[10.153.26.16:5701] 
     targetMember= Member [10.153.26.16:5701], targetConn=Connection [/10.153.26.16:54604 -> Address[10.153.26.16:5701]] live=true, client=false, type=MEMBER, targetBlock=Block [2] owner=Address[10.153.26.16:5701] migrationAddress=null 
     cemClientNotificationsLock Re-doing [20] times! c:__hz_Locks : null 
14-Jul-2012 03:28:55 com.hazelcast.impl.ConcurrentMapManager 
INFO: /10.152.41.105:5701 [cem-prod] ======= 57: CONCURRENT_MAP_LOCK ======== 
     thisAddress= Address[10.152.41.105:5701], target= Address[10.153.26.16:5701] 
     targetMember= Member [10.153.26.16:5701], targetConn=Connection [/10.153.26.16:54604 -> Address[10.153.26.16:5701]] live=true, client=false, type=MEMBER, targetBlock=Block [2] owner=Address[10.153.26.16:5701] migrationAddress=null 
     cemClientNotificationsLock Re-doing [30] times! c:__hz_Locks : null

Après plusieurs redémarrages de serveurs (tous ensemble, arrêtez tous et démarrez un par un, etc), nous avons pu exécuter le système. Pourriez-vous expliquer, pourquoi Hazelcast ne parvient pas à verrouiller la carte au niveau du nœud si celui-ci est dans le cluster, ou si ce nœud était hors cluster, pourquoi est-il affiché en tant que membre? Existe-t-il des recommandations pour redémarrer le cluster Tomcat avec des structures Hazelcast distribuées (arrêter tous les nœuds et commencer ensemble, arrêter et démarrer un par un, arrêter Hazelcast avant le redémarrage du serveur, etc.)? Merci!

Source

2012-07-20 dbf

Pouvez-vous expliquer, pourquoi Hazelcast ne parvient pas à verrouiller la carte au niveau du nœud si elle est dans le cluster

carte peut être verrouillée par un autre nœud au moment.

Il y a aussi beaucoup de corrections et de changements depuis le 1.9.4.4, c'est une version assez ancienne. Vous devriez essayer 2.1+.

Source

2012-07-21 12:59:20 mmdogan

merci pour votre aide, je suis heureux de voir des développeurs Hazelcast ici. Je vais essayer une nouvelle version de Hazelcast. Pourriez-vous également suggérer cette erreur: pastie.org/4305956 - c'est quand un noeud essaie de mettre de la valeur dans le cache distribué après le redémarrage du serveur. Il y a le noeud 10.152.41.105 dans le cluster, mais un des noeuds essaie d'y mettre et il échoue. A-t-il la même cause (l'un des serveurs verrouille la carte)? Merci. – dbf

Problème avec Hazelcast/CONCURRENT_MAP_LOCK après le redémarrage du serveur

Répondre

Questions connexes