Clusters de courtiers

Les problèmes suivants affectent les clusters de courtiers.

• Le courtier à haute disponibilité avec le magasin de données de clusters MySQL ne parvient pas à redémarrer s'il se termine de façon anormale (bogue 6896877).

  Solution : il s'agit d'un problème connu lié au cluster MySQL (http://bugs.mysql.com/bug.php?id=47955). Une correction destinée à résoudre ce problème a été appliquée aux versions MySQL 5.1.39-ndb-6.3.28, 5.1.39-ndb-7.0.9 et 5.1.39-ndb-7.1.0.

• Seuls les clusters de courtiers complètement connectés sont pris en charge par cette version. Autrement dit, tous les courtiers d'un cluster doivent communiquer directement avec tous les autres. Si vous essayez de connecter les courtiers dans un cluster conventionnel à l'aide de l'argument de ligne de commande imqbrokerd -cluster, assurez-vous que tous les courtiers du cluster sont bien inclus.

• Si un client est connecté à un courtier dans un cluster de courtiers amélioré, l'exécution client tentera de se reconnecter jusqu'à ce qu'elle y parvienne (elle ignore la valeur de l'attribut de connexion par défaut imqAddressListIterations).

• Un client ne peut naviguer que dans les contenus des files d'attente situées sur le courtier qui l'héberge. Il peut toutefois continuer d'envoyer des messages vers les files d'attente ou de consommer les messages provenant des files d'attente sur n'importe quel courtier du cluster, la restriction ne s'appliquant qu'à la navigation.

• Dans un cluster conventionnel avec des courtiers de version 4.3, tous les courtiers doivent avoir la version 3.5 ou ultérieure.

• Les courtiers de Message Queue 4.1, 4.2 et 4.3 ne peuvent pas interopérer dans un cluster par défaut avec les courtiers de Message Queue 3.6 ou 3.7 car la valeur par défaut de imq.autocreate.queue.maxNumActiveConsumers a été modifiée entre ces versions. (Bogue 6716400)

  Solution : vérifiez que tous les courtiers ont la même valeur ou modifiez la valeur de imq.autocreate.file.maxNumActiveConsumers, généralement appliquée par la modification de la configuration de Message Queue 4.1, 4.2 et 4.3 afin de correspondre à celle utilisée par les courtiers de la version 3.6 ou 3.7 (par défaut, de la valeur de -1 à 1, valeur par défaut de la version précédente).

• Pour ajouter un courtier de Message Queue 4.3 (ou 4.x) à un cluster de courtiers de Message Queue 3.x, un courtier maître doit être en cours d'exécution. (Bogue 6763796)

• Lors de la conversion d'un cluster conventionnel en cluster amélioré, vous pouvez utiliser l'utilitaire de gestionnaire de bases de données de Message Queue (imqdbmgr ) pour convertir un magasin de données basé sur JDBC autonome existant en magasin de données basé sur JDBC partagé comme indiqué à la section Cluster Conversion: JDBC-Based Data Store du Sun GlassFish Message Queue 4.4 Administration Guide.

• Un courtier utilisant HADB ne peut pas gérer des messages supérieurs à 10 Mo. (Bogue 6531734)

• Ce processus de conversion, effectué à l'aide de la commande imqdbmgr upgrade hastore, peut échouer. Le message « nombre de verrous trop élevé » s'affiche si le magasin contient plus de 10 000 messages. (Bogue 6588856)

  Solution : utilisez la commande suivante pour augmenter le nombre de verrous.

  hadbm set NumberOfLocks=<desiredNumber>

  Pour de plus amples informations, reportez-vous à la section « HADB Problems » du Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.

• Si plus de 500 messages distants sont validés dans une transaction, le courtier peut renvoyer l'erreur « HADB-E-12815 : espace de mémoire tableau épuisé ». (Bogue 6550483)

  Pour de plus amples informations, reportez-vous à la section « HADB Problems » du Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.

• Dans un cluster de courtiers, un courtier place des messages en file d'attente sur une connexion distante qui n'a pas été initiée. (Bogue 4951010)

  Solution : le consommateur recevra les messages dès qu'il se connecte. Les messages seront renvoyés à un autre consommateur si la connexion du consommateur reste fermée.

• Lorsque plusieurs messages sont consommés à partir d'un courtier distant dans une transaction, il est possible que le message d'erreur suivant soit consigné vers le courtier. Celui-ci n'est pas important et peut donc être ignoré :

  [26/Jul/2007:13:18:27 PDT] WARNING [B2117]: 
  Message acknowledgement failed from 
  mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
      ackStatus = NOT_FOUND(404)\
      Reason = Update remote transaction state to COMMITED(6): 
  transaction 3534784765719091968 not found, the transaction
  may have already been committed.
      AckType = MSG_CONSUMED
      MessageBrokerSession = 3209681167602264320
      TransactionID = 3534784765719091968
          SysMessageID = 8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690
          ConsumerUID = 3534784765719133952\par
  
  [26/Jul/2007:13:18:27 PDT] WARNING Notify commit transaction 
  [8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690, 
  [consumer:3534784765719133952, type=NONE]]
  TUID=3534784765719091968 got response: 
  com.sun.messaging.jmq.jmsserver.util.BrokerException:
   Update remote transaction state to COMMITED(6): 
    transaction 3534784765719091968 not found, the transaction may have already 
    been committed.:
  com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction 
  state to COMMITED(6): transaction 3534784765719091968 not found, the transaction
   may have already been committed.r

  Ce message est consigné lors de la notification de validation au courtier de base du message pour les prochains messages de la transaction lorsque la valeur de la propriété imq.txn.reapLimit est faible par rapport au nombre de messages distants contenus dans une transaction. (Bogue 6585449)

  Solution : pour ne pas recevoir ce message, augmentez la valeur de la propriété imq.txn.reapLimit.