Clusters de courtier

Les problèmes suivants affectent les courtiers clusterisés.

• Seuls les clusters de courtier entièrement 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 à l'aide de l'argument de ligne de commande imqbrokerd -cluster, assurez-vous que tous les courtiers du cluster sont bien inclus.

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

• Si un client est connecté à un courtier haute disponibilité, l'exécution client effectue des tentatives de reconnexion jusqu'à ce que celle-ci réussisse (quelle que soit la valeur de imqAddressListIterations.)

• Un client connecté à un courtier appartenant à un cluster ne peut actuellement pas utiliser QueueBrowser pour parcourir les files d'attente situées sur les courtiers distants de ce cluster. Il ne peut que parcourir le contenu des files d'attente situées sur le courtier auquel il est directement connecté. 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 limitation ne s'appliquant en effet qu'à la navigation.

• Dans un cluster conventionnel, si vous souhaitez clusteriser un courtier 4.1 avec un courtier 3.x, vous devez définir la propriété imq.autocreate.queue.maxNumActiveConsumers=1 pour le courtier 4.1. Sinon, les courtiers ne seront pas en mesure d'établir une connexion au cluster.

• Lors de la conversion en un cluster haute disponibilité, vous pouvez utiliser l'utilitaire Message Queue Manager (imqdbmgr) pour convertir un magasin de données persistantes HADB autonome en un magasin HADB partagé. Pour ce faire, utilisez la commande suivante.

  imqdbmgr upgrade hastore

  Vous pouvez utiliser cet utilitaire dans les cas suivants :

  • Basculement d'un magasin HADB autonome 4.0 à un magasin HADB partagé 4.1. Dans ce cas, le courtier met le magasin automatiquement à niveau. Vous pouvez ensuite exécuter la commande imqdbmgr pour convertir le magasin de données mis à niveau en vue d'une utilisation partagée.

  • Basculement d'un magasin HADB autonome 4.1 à un magasin HADB partagé. Dans ce cas, il vous suffit d'exécuter la commande imqdbmgr susmentionnée pour convertir le magasin de données en vue d'une utilisation partagée.

  Étant donné que cette commande prend uniquement en charge la conversion de magasins HADB, vous ne pouvez pas l'utiliser pour convertir des magasins basés sur des fichiers ou tout autre magasin JDBC en un magasin HADB partagé. Si vous utilisiez auparavant une version 3.x de Message Queue, vous devez créer un magasin HADB, puis migrer manuellement vos données vers ce magasin pour pouvoir utiliser la fonctionnalité de haute disponibilité.

• 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. (ID de 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é.» (ID de 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 non démarrée (ID de bogue 4951010).

  Solution : le consommateur recevra les messages une fois la connexion démarré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.