Clusters de courtiers

Les problèmes suivants affectent les clusters de courtiers.

• 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 haute disponibilité, l'exécution client tentera de se reconnecter jusqu'à ce qu'elle y parvienne (elle ignore la valeur de l'attribut d'usine de connexion 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.2, tous les courtiers doivent avoir la version 3.5 ou ultérieure.

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

  Solution : remplacez la valeur par défaut de la chaîne des courtiers de Message Queue 4.2 et 4.1, imq.autocreate.queue.maxNumActiveConsumers (-1) par la valeur par défaut de la version précédente (1).

• Lors de la conversion d'un cluster conventionnel en cluster haute disponibilité, vous pouvez utiliser l'utilitaire du Gestionnaire de base de données de Message Queue (imqdbmgr ) pour convertir un magasin de données basé sur un JDBC autonome en un magasin de données haute disponibilité partagé. Cette procédure est documentée dans Converting a Standalone Data Store to a Shared Data Store du Sun Java System Message Queue 4.2 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, en affichant le message « nombre de verrous trop élevé » 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 manuel 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 de table épuisé.” (Bogue 6550483)

  Pour de plus amples informations, reportez-vous à la section « HADB Problems » du manuel 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 démarré (Bogue 4951010)

  Solution : Le consommateur recevra les messages dès que la connexion est initiée. Les messages seront renvoyés à un autre consommateur si la connexion du consommateur est 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]:
  Échec de la réception du message à partir de
  mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
      ackStatus = NOT_FOUND(404)\
      Raison = Mise à jour de l'état de la transaction distante sur COMMITED(6) :
  transaction 3534784765719091968 introuvable, celle-ci a déjà dû être validée.
      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 Notifier la validation d'une 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:
   Mise à jour de l'état de la transaction distante sur COMMITED(6) :
    transaction 3534784765719091968 introuvable, celle-ci a déjà dû être validée.:
  com.sun.messaging.jmq.jmsserver.util.BrokerException: Mise à jour de la transaction distante sur
  COMMITED(6) : transaction 3534784765719091968 introuvable, celle-ci a déjà dû
   être validée.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.