test

Notes de version de Sun GlassFish Message Queue 4.4

Nouvelles fonctions de Message Queue 4.1

Message Queue 4.1 était une version mineure apportant un certain nombre de nouvelles fonctions, des améliorations de fonctions et des corrections de bogues. Cette section décrit les nouvelles fonctions de la version 4.1 et fournit de plus amples références destinées à votre usage :

Pour obtenir des informations sur les nouvelles fonctions de Message Queue 4.0, reportez-vous à la section Nouvelles fonctions de Message Queue 4.0.

Clusters de courtiers haute disponibilité

Message Queue 4.1 a introduit un nouveau cluster de courtiers amélioré. Comparés aux clusters de courtiers traditionnels assurant la disponibilité du service de messagerie (si un courtier échoue, un autre courtier est disponible pour fournir un service de messagerie), les clusters de courtiers améliorés assurent eux la disponibilité des données (si un courtier échoue, ses messages persistants et données d'état sont disponibles pour qu'un autre courtier puisse le relayer et délivrer les messages).

L'implémentation de haute disponibilité introduite dans Message Queue 4.1 utilise un magasin de données basé sur JDBC partagé : plutôt que tous les courtiers d'un cluster de courtiers disposent de leur propre magasin de données persistantes, tous les courtiers du cluster partagent la même base de données compatible JDBC. Si un courtier particulier échoue, un autre courtier du cluster prend sa relève pour acheminer et livrer ses messages. Le courtier de basculement utilise alors les données et les informations d'état du magasin de données partagées. Les clients du courtier défaillant ayant émis les messages se reconnectent au courtier de basculement, et le service de messagerie est ininterrompu.

Le magasin partagé basé sur JDBC utilisé dans l'implémentation haute disponibilité de Message Queue 4.1 doit être lui-même hautement disponible. Si vous ne possédez pas de base de données hautement disponible ou si la livraison ininterrompue de messages n'est pas importante pour vous, vous pouvez continuer à utiliser les clusters traditionnels qui fournissent une disponibilité de service sans disponibilité de données.

Pour configurer un cluster de courtiers amélioré pour Message Queue 4.1, vous devez spécifier les propriétés de courtier suivantes pour chaque courtier du cluster :

L'implémentation de clusters de courtiers améliorés se fait selon les étapes suivantes :

  1. Installez une base de données hautement disponible.

  2. Installez le fichier .jar du pilote JDBC.

  3. Créez le schéma de base de données pour le magasin de données persistant hautement disponible.

  4. Paramétrez des propriétés haute disponibilité pour chaque courtier du cluster.

  5. Démarrez chaque courtier du cluster.

Si vous souhaitez consulter une discussion conceptuelle sur les clusters de courtiers améliorés et obtenir une comparaison de ceux-ci par rapport aux clusters conventionnels, reportez-vous au Chapitre 4, Broker Clusters du Sun GlassFish Message Queue 4.4 Technical Overview. Pour obtenir des informations procédurales et référentielles sur les clusters de courtiers améliorés, reportez-vous au Chapitre 10, Configuring and Managing Broker Clusters du Sun GlassFish Message Queue 4.4 Administration Guide et à la section Cluster Configuration Properties du Sun GlassFish Message Queue 4.4 Administration Guide.

Si vous avez utilisé une base de données hautement disponible avec Message Queue 4.0 et si vous souhaitez passer à un cluster de courtiers amélioré, vous pouvez utiliser l'utilitaire Gestionnaire de base de données (imqdbmgr) pour une conversion vers un magasin de données persistant partagé. Reportez-vous également à Clusters de courtiers pour plus de problèmes et restrictions connus.

Prise en charge de JAAS

En plus des mécanismes d'authentification intégrés basés sur les fichiers et le LDAP, Message Queue introduit également la prise en charge de JAAS (Java Authentication and Authorization Service), qui vous permet de connecter un mécanisme d'authentification au courtier pour authentifier les clients Message Queue.

Pour obtenir une description des informations qu'un courtier met à disposition d'un service d'authentification conforme à JAAS et une explication sur la façon de configurer le courtier pour utiliser un tel service, reportez-vous à la section Using JAAS-Based Authentication du Sun GlassFish Message Queue 4.4 Administration Guide.

Modification du format du magasin de données persistant

Message Queue 4.1 a modifié le magasin de données basé sur JDBC pour prendre en charge des clusters de courtiers améliorés. Pour cette raison, le format du magasin de données basé sur JDBC est passé à la version 410. Les versions aux formats 350, 370 et 400 sont automatiquement migrées vers la version 410.

Veuillez noter que le format du magasin de données persistant basé sur les fichiers reste à la version 370 car aucun changement n'a été apporté à cette version.

Configuration de l'environnement du courtier

La propriété IMQ_DEFAULT_EXT_JARS a été ajoutée au fichier de configuration de l'environnement Message Queue 4.1 imqenv.conf. Vous pouvez définir cette propriété pour spécifier les noms de chemin des fichiers .jar externes à inclure dans CLASSPATH au démarrage du courtier. Si vous utilisez cette propriété pour spécifier l'emplacement des fichiers .jar externes, il ne vous sera plus nécessaire de copier ces fichiers dans le répertoire lib/ext. Ces fichiers .jar externes peuvent faire référence aux pilotes JDBC ou aux modules de connexion JAAS. L'exemple de propriété suivant spécifie l'emplacement des pilotes JDBC.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Prise en charge de Java ES Monitoring Framework

Message Queue 4.1 a introduit la prise en charge de Sun Java Enterprise System (Java ES) Monitoring Framework, qui permet de surveiller les composants Java ES à l'aide d'une interface graphique commune. Cette interface est implémentée par une console basée sur le Web, Sun Java System Monitoring Console. Les administrateurs peuvent utiliser la console pour visualiser les statistiques de performance, créer des règles de surveillance automatique et accuser réception des alarmes. Si vous exécutez Message Queue en même temps que d'autres composants Java ES, vous trouverez peut-être plus pratique d'utiliser une seule interface pour tous les gérer.

Pour obtenir des informations sur l'utilisation de Java ES Monitoring Framework pour surveiller Message Queue, reportez-vous à XREF.

Gestion améliorée des transactions

Auparavant, seules les transactions à l'état PREPARED pouvaient être annulées administrativement. Par exemple, lorsqu'une session, faisant partie d'une transaction distribuée, ne s'arrêtait pas normalement, la transaction était conservée à un état qui ne pouvait pas être nettoyé par un administrateur. Dans Message Queue 4.1, vous pouvez désormais utiliser l'utilitaire Commande (imqcmd) pour nettoyer (annuler) des transactions dont l'état est l'un des suivants : STARTED, FAILED, INCOMPLETE, COMPLETE et PREPARED.

Pour vous aider à déterminer si une transaction particulière peut être annulée ou pas (en particulier son état n'est pas PREPARED), l'utilitaire Commande fournit des données supplémentaires dans la sortie imqcmd query txn : il fournit l'ID de connexion pour la connexion à l'origine de la transaction et indique l'heure à laquelle la transaction a été créée. À l'aide de ces informations, un administrateur peut alors décider d'annuler ou non la transaction. En règle générale, il est préférable que l'administrateur évite d'annuler une transaction prématurément.

Ports fixes pour les connexions de clients C

Dans Message Queue 4.1, les clients C, comme les clients Java, peuvent maintenant se connecter à un port de courtier fixe plutôt qu'à un port affecté de façon dynamique par le service du courtier Port Mapper. Les connexions de port fixe sont utiles si vous essayez de franchir un pare-feu ou si avez besoin de contourner le service Port Mapper pour d'autres raisons.

Pour configurer une connexion de port fixe, vous devez configurer à la fois l'exécution du courtier et du client C (les deux extrémités de la connexion). Par exemple, si vous souhaitez connecter votre client via ssljms au port 1756, il vous faut procéder comme suit :

Remarque –

La propriété de connexion MQ_SERVICE_PORT_PROPERTY a été reportée dans Message Queue 3.7 Mise à jour 2.