Notes de mise à jour de Sun ONE Message Queue 3.0.1 SP2

Notes de mise à jour de Sun™ ONE Message Queue

Version 3.0.1 SP2

Numéro de document 817-3826-10

Août 2003

Ces notes de mise à jour contiennent des informations importantes connues au moment de la mise sur le marché de la version 3.0.1 Service Pack 2 (SP2) de Sun™ Open Net Environment
(Sun ONE) Message Queue (MQ). Vous y trouverez des renseignements sur les nouvelles fonctions, les améliorations, les restrictions et problèmes connus, les notes techniques, etc. Prenez connaissance de ce document avant de commencer à utiliser MQ 3.0.1 SP2.

Vous trouverez la dernière version de ces notes de mise à jour sur le site Web de la documentation Sun ONE : http://docs.sun.com/?p=/coll/S1_MessageQueue_301. Consultez ce site Web avant d'installer et de configurer votre logiciel, puis régulièrement pour vous procurer les manuels et les notes de mise à jour les plus récents.

Ces notes de mise à jour contiennent les sections suivantes :

Historique des mises à jour

Tableau 1  Historique des mises à jour 

Date

Description des modifications

Août 2003

Les modifications suivantes ont été apportées au document :

Octobre 2002

Première version du document.

Compatibilité avec Java™ Message Service (JMS)

MQ 3.0.1 a été reconnu compatible avec la spécification Java Message Service (JMS) 1.1 après avoir satisfait aux tests CTS (Compatibility Test Suite) de JMS 1.1.

MQ3.0.1, fournisseur JMS natif de Sun ONE Application Server 7, a également satisfait aux tests CTS J2EE 1.3.1 de Sun ONE Application Server 7 (qui doit être compatible avec JMS 1.0.2b).

Nouveautés de Message Queue 3.0.1 SP2

MQ 3.0.1 SP2 est une mise à jour de MQ 3.0.1 SP1 (qui était une version de correction des problèmes, ne contenant aucune nouvelle fonction). MQ 3.0.1 SP1 était une mise à jour de MQ 3.0.1. Dans ces notes de versions, les références aux versions 3.0.1 concernent généralement 3.0.1, 3.0.1 SP1 et 3.0.1 SP2.

MQ 3.0.1 SP2 intègre toutes les nouvelles fonctions de MQ 3.0 et 3.0.1, auxquelles s'ajoutent deux fonctions de 3.0.1 SP2.

Nouvelles fonctions de Message Queue 3.0.1 SP2

Deux fonctions supplémentaires distinguent MQ 3.0.1 SP2 de MQ 3.0.1 :

Nouvelles fonctions de Message Queue 3.0.1

Deux fonctions supplémentaires distinguent MQ 3.0.1 de MQ 3.0 :

Nouvelles fonctions de Message Queue 3.0

MQ 3.0 a apporté un certain nombre de changements par rapport à la version 2.0 du produit : iMQ 2.0 (et iMQ 2.0, Service Pack 1).

Par exemple, il existe désormais deux éditions du produit : Platform Edition et Entreprise Edition.

Platform Edition :     fournit une prise en charge JMS de base. Cette édition convient plus particulièrement aux environnements de développement et de déploiement à petite échelle.

Enterprise Edition :     fournit une prise en charge du protocole HTTP/HTTPS et offre une capacité d'évolution et des fonctions de sécurité améliorées. Cette édition convient plus particulièrement aux déploiements à grande échelle.

(Pour plus d'informations sur ces éditions, consultez la section Introduction du document Administrator's Guide de MQ ou du document Developer's Guide de MQ.)

Les descriptions ci-dessous relatives aux modifications apportées à MQ 3.0.1, sont regroupées en fonction de leur appartenance aux deux éditions ou à l'édition Entreprise Edition uniquement.

Enterprise Edition et Platform Edition

Enterprise Edition uniquement

Mises à jour de la documentation Message Queue

La documentation de MQ 3.0.1 et MQ 3.0.1 SP2 a été mise à jour à partir de la version 3.0 du produit. Ces mises à jour se trouvent sur le site Web de la documentation Sun ONE : http://docs.sun.com/coll/S1_MessageQueue_301.

Installation Guide

Le document Installation Guide de MQ a été mis à jour pour refléter les changements apportés à MQ 3.0.1 SP2 (consultez la rubrique "Nouvelles fonctions de Message Queue 3.0.1 SP2").

Administrator's Guide

Le document Administrator's Guide de MQ a été mis à jour avec les nouvelles fonctions de MQ 3.0.1 (consultez la rubrique "Nouvelles fonctions de Message Queue 3.0.1").

Developer's Guide

Le document Developer's Guide de MQ a été mis à jour avec les nouvelles fonctions de MQ 3.0.1 (consultez la rubrique "Nouvelles fonctions de Message Queue 3.0.1").

Problèmes de compatibilité

Les versions 3.0.1 de MQ sont entièrement compatibles avec la version 3.0 de MQ et la mise à niveau de MQ 3.0 vers MQ 3.0.1 ne nécessite aucune modification de la configuration du courtier, des objets gérés, des outils d'administration ou des applications clientes.

Cependant, les versions 3.0.1 de MQ (nommées 3.0.1 ci-après dans cette section) ne sont généralement pas compatibles avec iMQ 2.0. Vous pouvez être amené à résoudre un certain nombre de problèmes lors de la mise à niveau de iMQ 2.0 (ou iMQ 2.0 Service Pack 1) vers MQ 3.0.1 :

Compatibilité du courtier

L'interaction entre un courtier MQ 3.0.1 et un courtier iMQ 2.0 ne fonctionne pas du fait des modifications apportées aux propriétés du courtier et au schéma de la banque permanente. Toutefois, certaines données iMQ 2.0 sont compatibles avec MQ 3.0.1, comme l'indique le Tableau 2 et peuvent être conservées lors de la mise à niveau vers MQ 3.0.1. Lors de la mise à niveau de iMQ 2.0 vers MQ 3.0.1, vous devez prendre en considération les éléments suivants :

Compatibilité des objets gérés

MQ De nouveaux attributs ont été ajoutés aux objets gérés par 3.0.1 et les attributs iMQ 2.0 ont été renommés. C'est pourquoi, lors de la mise à niveau de iMQ 2.0 vers MQ 3.0.1, vous devez prendre en considération les éléments suivants :

Compatibilité de l'outil d'administration

Du fait de l'attribution d'un nouveau nom pour plusieurs fichiers et répertoires (en particulier lors du remplacement de la chaîne "jmq" par "imq"), tous les utilitaires de ligne de commande, les propriétés de courtiers, les attributs d'objets gérés et les noms des fichiers internes de MQ 3.0.1 ont été modifiés. C'est pourquoi, lors de la mise à niveau de iMQ 2.0 vers MQ 3.0.1, vous devez prendre en considération les éléments suivants :

Compatibilité du client

Lors de la mise à niveau de iMQ 2.0 vers MQ 3.0.1, vous devez prendre en considération les éléments suivants :

Restrictions connues

Les restrictions abordées dans cette section sont regroupées en fonction de leur appartenance à Enterprise Edition et Platform Edition des versions 3.0.1 de MQ ou à Enterprise Edition uniquement.

Enterprise Edition et Platform Edition

Enterprise Edition uniquement

Problèmes connus

Cette section répertorie les principaux problèmes connus au moment de la sortie de MQ 3.0.1 SP2.

Pour connaître la liste des problèmes en cours, leur état et les solutions possibles, les membres de Java Developer Connection (TM) doivent consulter la page "Bug Parade" du site Web Java Developer Connection. Avant de signaler tout nouveau problème, merci de consulter cette page. Bien que tous les problèmes de MQ n'y soient pas répertoriés, il est bon de s'y référer pour savoir si un problème a déjà été signalé.

La page concernée est la suivante :

Pour signaler un nouveau problème ou soumettre une demande d'amélioration, envoyez un courrier électronique à l'adresse imq-feedback@sun.com.

Tableau 3  Description des problèmes 

Référence

Détails

4431924

imqadmin: les boîtes de dialogue qui exigent une réponse de l'utilisateur peuvent se bloquer.

La console d'administration (imqadmin) utilise des boîtes de dialogue qui ont un comportement applicatif. La majorité de ces boîtes de dialogue s'affichent par interaction avec l'interface utilisateur graphique, par exemple en sélectionnant l'option de menu Ajouter courtier. Néanmoins, l'affichage d'une boîte de dialogue peut également provenir de la perte de connexion avec le courtier. Lorsque plusieurs boîtes de dialogue sont ouvertes, la console d'administration est verrouillée. Vous ne pouvez pas faire disparaître des boîtes de dialogue exigeant une réponse de l'utilisateur à l'aide du bouton Fermer.

Solution : faites disparaître la boîte de dialogue au premier plan en utilisant les contrôles de gestion de fenêtre :

       - la case X en haut à droite de la fenêtre sous Windows ;

       - l'option de menu du gestionnaire de fenêtres Fermer sous Solaris.

4449354

Exceptionnellement, l'appel simultané des méthodes Connection.stop, Connection.start, Connection.close et des méthodes Session.recover et Session.rollback (dans des threads distinctes) peut aboutir à une commande de nouvelle livraison de message inattendue.

Solution : assurez-vous que vos appels aux méthodes Connection… et Session… indiquées précédemment sont effectués en série, soit en utilisant la même thread, soit la synchronisation.

4683029

L'option -javahome dans tous les scripts Solaris/Windows ne fonctionne pas si la valeur comprend un espace.

L'option -javahome est utilisée par les commandes et les utilitaires de MQ pour indiquer un autre exécuteur Java 2 compatible. Néanmoins, le chemin d'accès de l'autre exécuteur Java ne doit pas contenir d'espace.

Vous trouverez ici des exemples de chemin ayant des espaces :

      Windows :

      C:\jdk 1.4 (sous Windows les espaces sont autorisés dans le chemin si celui-ci est entouré de guillemets, comme dans l'exemple "C:\jdk 1.4")

      Solaris :

      /work/java 1.4

Solution : installez l'exécuteur Java à un emplacement ou un chemin ne contenant pas d'espace.

4689962

Avec les paramètres régionaux japonais, le résultat des divers utilitaires administratifs n'est pas aligné correctement dans les colonnes et les bordures sont trop courtes.

Solution : aucune.

4703406

QueueBrowser doit fonctionner sans appeler connection.start().

Connection.start() doit être appelé au cours d'une connexion avant que QueueBrowser puisse parcourir la file d'attente. En cas d'échec de l'appel de Connection.start(), l'énumération QueueBrowser se bloque sur nextElement() et peut déclencher une exception java.util. NoSuchElementException.

Solution : appelez Connection.start() avant QueueBrowser.getEnumeration().

4753010

Croissance illimitée du segment mémoire natif du processus Java avec un serveur VM.

Il s'agit d'un problème VM qui peut avoir une incidence sur le processus du courtier en cas d'ouvertures et fermetures rapides des connexions client. Il peut provoquer une croissance continue et illimitée de la mémoire du processus du courtier. Ce dernier peut même s'arrêter brutalement lorsque la totalité de la mémoire du système est épuisée.

Vous pouvez contrôler la croissance du segment de mémoire natif à l'aide de l'outil /usr/proc/bin/pmap.

Solution : forcez le courtier à utiliser le client VM, à l'aide de l'option de commande suivante :

    imqbrokerd -clientvm

Vous pouvez également supprimer l'argument -server du script Shell /usr/bin/imqbrokerd qui lance le courtier, ou encore mettre à niveau vers JDK 1.4.1 et utiliser l'option de commande suivante :

    imqbrokerd -javahome répertoire_JDK_1.4.1

4761626

Une forte demande de création/suppression avec des files d'attente créées automatiquement peut provoquer la perte de messages.

Dans des situations exceptionnellement chargées, un message d'une file d'attente de destination créée automatiquement peut se perdre.

L'erreur se produit si, après que tous les messages livrés à partir d'une file d'attente ont été acquittés, le consommateur du dernier message de la file est supprimé en même temps qu'un nouveau producteur de message (d'une autre connexion) envoie un message à cette file d'attente. En réalité, le contenu de la file d'attente est supprimé automatiquement (elle est vide, sans consommateur) au moment où le nouveau message arrive, ce qui entraîne la perte de celui-ci.

Solution : créez des files d'attente à l'aide des outils d'administration de MQ.

4879448

Sun ONE Message Queue version 3.0.1 ne bascule pas sur disque les messages permanents lorsque le segment de mémoire est saturé.

Une expression booléenne permet de déterminer si la logique d'un message est correcte ou non. Si la logique n'est pas correcte, le message doit être exclu. Cela signifie que, parfois, certains messages permanents peuvent être exclus de la mémoire. Si la possibilité de basculer les messages non permanents est désactivée, elle est toujours active pour les messages permanents.

Solution : définissez la propriété de courtier suivante dans le fichier config.properties ou par l'intermédiaire de la ligne de commande :
imqmemory_management.swapNPMsps=false

4883126

La fonction de reconnexion automatique ne fonctionne pas correctement.

Le nombre de consommateurs augmente après chaque opération de reconnexion, ce qui provoque l'envoi de messages en double par le courtier.

Solution : aucune. Ce problème sera résolu dans la version 3.5 de MQ.

4888270

La retransmission d'un message envoyé à l'origine dans une transaction provoque une erreur du courtier.

Si un message envoyé à l'origine dans une transaction est   reçu et retransmis dans une session sans transaction, le courtier signale une erreur.

Solution : n'utilisez pas le même objet message. Si vous voulez vraiment retransmettre le message, utilisez un nouveau message distinct.

4893546

Le courtier ne libère pas la mémoire lorsqu'il est utilisé avec le JDK 1.4.2 et le serveur VM.

Solution : utilisez le client VM. Le courtier doit être lancé à l'aide de la commande suivante :

imqbrokerd -clientvm

Problèmes résolus dans les versions 3.0.1 de Message Queue

Vous trouverez ci-dessous une brève description des principaux problèmes qui ont été corrigés dans MQ 3.0.1, 3.0.1 SP1 et 3.0.1 SP2.

Pour connaître la liste des problèmes résolus dans MQ 3.0, consultez les notes de mise à jour de MQ 3.0 disponibles à l'adresse

Pour obtenir un rapport complet sur les problèmes suivants, consultez le site Java Developer Connection à l'adresse

Tableau 4  Problèmes résolus dans les versions 3.0.1 de MQ  

Référence

Description

4679837

Le client déclenche parfois une exception JMSException lors d'une commande connection.close() lorsque TLS est utilisé comme transport.

4683129

L'horodatage du journal du courtier est incorrect entre minuit et 1 heure.

4688051

Le client peut obtenir une exception EOFException si des connexions sont ouvertes et fermées rapidement avec le courtier.

4694971

Même après une XAConnection.close() normale et exempte d'erreur, une transaction JTS/XA autonome peut parfois échouer.

4700851

Le client ne nettoie pas la transaction locale après la fin d'une transaction XA.

4701982

La console d'administration ne peut pas être lancée sous Solaris ou Linux si la variable d'environnement CLASSPATH est définie.

4702152

Pour les messages acquittés lors d'une transaction côté consommateur, le courtier conserve des informations d'état superflues pour chaque message acquitté jusqu'à ce que le consommateur soit fermé.

4704186

Corrections dans le fichier README des exemples d'applications (demo/jms/README)

4735757

Un consommateur déclenche une exception si plus de 50 messages sont reçus au cours d'une transaction avant d'appeler commit().

4758424

Les performances des files d'attente circulaires se détériorent lorsque le backlog atteint >10 000 messages.

4758427

Les consommateurs de files d'attente circulaires peuvent rester bloqués si le dernier message de la file d'attente expire avant sa livraison.

4770212

Le fait d'effectuer une pause et de reprendre un service suspend les connexions client si celles-ci n'ont pas de message en attente.

4770518

Le service de courtier de Windows prend fin lors de la déconnexion.

4809079

Le courtier ne s'arrête pas correctement s'il existe des connexions de type SSL.

4821708

Session.createProducer(null) déclenche une exception NullPointerException.

4828860

Les performances de MQ se détériorent avec le sélecteur : la situation empire au fur et à mesure que le nombre de clients augmente.

4835586

Sauvegarde du courtier principal : le cycle de restauration peut entraîner la perte des informations de destination.

4879448

Dans certaines circonstances, le courtier ne bascule pas les messages sur le disque.

Fonctionnalités considérées comme facultatives dans JMS

La spécification JMS donne des précisions sur certains éléments facultatifs. Chaque fournisseur JMS décide ou non de les mettre en uvre. La façon dont MQ prend en compte ces éléments facultatifs est décrite ci-dessous :

Tableau 5  Fonctionnalités JMS facultatives  

Section de la spécification JMS

Description et prise en compte par MQ

3.4.3
JMSMessageID

"L'ID de message présentant quelques difficultés de création et augmentant la taille du message, certains fournisseurs JMS peuvent optimiser l'en-tête du message s'ils obtiennent l'indication que l'ID du message n'est pas utilisé par une application. C'est le producteur de message JMS qui indique de désactiver l'ID de message."

Prise en compte par MQ : le produit ne désactive pas la génération des ID de message (tous les appels à setDisableMessageID() dans MessageProducer sont ignorés). Tous les messages contiennent une valeur MessageID correcte.

3.4.12
Overriding Message Header Fields

"JMS ne définit pas spécifiquement la manière dont un administrateur remplace ces valeurs de champ d'en-tête. Un fournisseur JMS n'est pas tenu de prendre en charge cette option administrative."

Prise en compte par MQ : MQ prend en charge le remplacement administratif des valeurs dans les champs d'en-tête de message par l'intermédiaire de la configuration des objets gérés de type usine de connexion.

3.5.9
JMS Defined Properties

"JMS réserve le préfixe de nom de propriété JMSX pour les propriétés définies par JMS."
"Sauf mention contraire, la prise en compte de ces propriétés est facultative."

Prise en compte par MQ : les propriétés JMSX définies par la spécification JMS 1.1 sont prises en charge par MQ.

3.5.10
Provider-specific Properties

"JMS réserve le préfixe de nom de propriété JMS_<nom_fournisseur>pour les propriétés spécifiques au fournisseur."

Prise en compte par MQ : les propriétés propres au fournisseur servent à fournir les fonctions nécessaires à l'utilisation de JMS avec des clients natifs des fournisseurs. Elles ne doivent pas être utilisées dans le cas de la messagerie JMS à JMS. MQ 3.0.1 n'utilise pas de propriétés spécifiques aux fournisseurs.

4.4.8
Distributed Transactions

"JMS n'a pas besoin qu'un fournisseur prenne en charge les transactions distribuées."

Prise en compte par MQ : les transactions distribuées sont prises en charge dans cette version de MQ.

4.4.9
Multiple Sessions

"Dans le cas du <modèle de distribution point à point PTP>, JMS ne spécifie pas la sémantique des autres QueueReceivers de la même file d'attente. Néanmoins, JMS n'empêche pas un fournisseur de le faire." Consultez la section 5.8 de la spécification JMS pour en savoir davantage.

Prise en compte par MQ : MQ prend en charge trois types de livraison pour les files d'attente : basculement, circulaire et simple (par défaut). Pour plus d'informations, consultez le document Administrator's Guide de MQ.

Notes techniques

Cette section couvre brièvement les rubriques suivantes :

Paramètres de l'horloge système

Lorsque vous utilisez un système MQ, assurez-vous que les horloges système sont bien synchronisées et évitez de les retarder.

Synchronisation recommandée

Il est conseillé de synchroniser toutes les horloges de tous les hôtes qui communiquent avec le système MQ. Cette phase est particulièrement importante si vous utilisez l'expiration (TimeToLive) des messages. Un défaut de synchronisation des horloges des hôtes peut provoquer le dysfonctionnement de TimeToLive (la livraison des messages peut être perturbée). Vous devez synchroniser les horloges avant de démarrer les courtiers.

Solaris     Vous pouvez utiliser la commande rdate sur un hôte local pour effectuer la synchronisation avec un hôte distant. (Pour ce faire, vous devez être superutilisateur, c'est-à-dire reconnu en tant que root). Par exemple, la commande suivante synchronise l'hôte local (appelons-le Host2) et l'hôte distant Host1 :

Linux     La commande est similaire à celle de Solaris, à laquelle s'ajoute l'option -s :

Windows     Vous pouvez utiliser la commande net et la sous-commande time pour synchroniser l'hôte local et l'hôte distant. Par exemple, la commande suivante synchronise l'hôte local (appelons-le Host2) et l'hôte distant Host1 :

Évitez de retarder les horloges système

Évitez de retarder l'horloge sur les systèmes qui exécutent un courtier MQ. En effet, MQ utilise l'horodatage pour identifier les objets internes tels que les transactions et les abonnements durables. Si l'horloge système est retardée, il devient en théorie possible qu'un identificateur interne existe en double. Le courtier tente d'y remédier en introduisant des données aléatoires dans les identificateurs et par la détection des écarts d'horloge en cours d'exécution, mais si l'horloge système est retardée de façon importante alors que le courtier n'est pas en cours d'exécution, il existe un risque de duplication des identificateurs.

Si vous avez besoin de retarder de plus de quelques secondes l'horloge sur un système sur lequel s'exécute un courtier, il est conseillé de le faire en l'absence de transactions ou d'abonnements durables, ou alors lorsque le courtier ne s'exécute pas, puis d'attendre que le délai spécifié s'écoule avant d'exécuter le courtier.

L'approche idéale consiste à synchroniser les horloges avant de démarrer les courtiers, puis d'utiliser une technique appropriée pour s'assurer que les horloges ne divergent pas de manière importante après-coup.

Restrictions de connexion dues au système d'exploitation sur les clients et les courtiers

Sur les plates-formes Linux et Solaris, le shell d'exécution du client ou du courtier impose une limite logicielle du nombre de descripteurs de fichiers utilisables par un client. Avec le système MQ, chaque connexion demandée par un client, ou chaque connexion acceptée par un courtier, utilise un de ces descripteurs de fichiers. Par conséquent, aucun courtier ou client ne peut dépasser la limite de 256 connexions sous Solaris et 1 024 connexions sous Linux sans changer cette limite. (Ce nombre est en fait légèrement inférieur, car certains descripteurs de fichiers sont utilisés à d'autres fins, notamment pour la permanence basée sur les fichiers.)

Pour modifier cette limite, consultez la page concernant ulimit ou les instructions du paragraphe "Augmentation des descripteurs de fichiers pour améliorer les performances de permanence basée sur les fichiers" ci-dessous. La limite doit être changée dans chaque shell d'exécution du client ou du courtier concerné.

Augmentation des descripteurs de fichiers pour améliorer les performances de permanence basée sur les fichiers

Sous les systèmes Solaris et Linux, la vitesse de stockage des messages dans la banque permanente basée sur les fichiers par défaut dépend du nombre de descripteurs de fichiers disponibles pour le stockage des fichiers. (Le nombre de descripteurs de fichiers n'est pas limité sous Windows.) Plus le nombre de descripteurs est élevé, plus le système est capable de traiter rapidement un grand nombre de messages permanents.

En vue d'améliorer le test des performances ou le déploiement, les administrateurs doivent augmenter le nombre maximal de descripteurs de fichiers disponibles pour une application (le cas échéant, le processus de courtier), puis augmenter la taille du pool de descripteurs de fichiers partagés utilisé par le courtier en modifiant la valeur de la propriété :

La valeur de cette propriété doit être inférieure au nombre maximal de descripteurs de fichiers disponibles sur le système.

Sous Solaris, par exemple, vous pouvez augmenter les limites prévues pour les descripteurs de fichiers par l'intermédiaire de la commande ulimit. Les processus héritent des limites système de leur shell parent (login). Sous Solaris, il existe une limite matérielle et une limite logicielle. Pour un utilisateur autre que l'utilisateur root, le nombre de descripteurs de fichiers pour une application ne peut dépasser la limite logicielle qui, à son tour, ne peut dépasser la limite matérielle.

Pour connaître les limites en vigueur des descripteurs de fichiers :

Pour modifier les limites des descripteurs de fichiers de l'utilisateur root :

Dès lors, tous les processus créés à partir de ce shell sont en mesure d'ouvrir les descripteurs de fichiers de manière illimitée. À ce stade, vous pouvez exécuter sans risque la commande imqbroker.

Pour modifier les limites des descripteurs de fichiers pour les utilisateurs autres que root :

où numéro1 est inférieur à 1 024 et numéro2 est inférieur à numéro1.

Si 1 024 s'avère insuffisant, vous disposez des possibilités suivantes :

Sécurisation des données permanentes

Le courtier utilise une banque permanente qui contient, entre autres, des fichiers de messages stockés provisoirement. Ces messages pouvant contenir des informations confidentielles, il est recommandé de protéger la banque de données contre les accès non autorisés.

Un courtier peut utiliser la permanence intégrée ou enfichable.

Banque permanente intégrée

Un courtier qui utilise la permanence intégrée écrit les données permanentes dans une banque de données ordinaire, situé à l'emplacement :

où NomCourtier est un nom qui identifie l'instance du courtier.

Le répertoire NomCourtier/filestore/ est créé lors du premier démarrage de l'instance du courtier. La procédure de protection de ce répertoire dépend du système d'exploitation sur lequel le courtier est exécuté.

Solaris et Linux     Les autorisations associées au répertoire IMQ_VARHOME/instances/NomCourtier/filestore/ dépendent du "umask" de l'utilisateur qui a démarré l'instance du courtier. Par conséquent, il est possible de restreindre les droits de démarrage d'une instance de courtier et de lecture de ses fichiers permanents par l'intermédiaire de umask. De même, un administrateur (superutilisateur) peut protéger les données permanentes en définissant la valeur 700 pour les autorisations d'accès au répertoire IMQ_VARHOME/instances.

Windows     Les autorisations d'accès au répertoire IMQ_VARHOME/instances/NomCourtier/filestore/ peuvent être définies grâce aux mécanismes de protection du système d'exploitation Windows utilisé. Cette opération s'effectue généralement par l'intermédiaire de la boîte de dialogue Propriétés du répertoire.

Banque permanente enfichable

Un courtier qui utilise la permanence enfichable écrit les données permanentes dans une base de données de type JDBC.

Dans le cas d'une base de données gérée par un serveur de bases de données (une base de données Oracle, par exemple), il est recommandé de créer un nom d'utilisateur et un mot de passe pour accéder aux tables de la base MQ (tables dont le nom commence par IMQ). Si la base de données ne permet pas de protéger individuellement les tables, créez une base de données spécifique, à l'usage exclusif des courtiers MQ. Consultez la documentation du fournisseur de base de données pour savoir comment gérer l'accès via un nom d'utilisateur et un mot de passe.

Le nom d'utilisateur et le mot de passe nécessaires pour que le courtier puisse établir une connexion avec la base de données peuvent faire partie des propriétés de configuration du courtier. Cela étant, il est plus sûr de les indiquer au niveau de la ligne de commande lors du démarrage du courtier (consultez l'annexe A (Setting Up Plugged-in Persistence) du document Administrator's Guide de MQ).

Dans le cas d'une base de données imbriquée, à laquelle le courtier accède par l'intermédiaire du pilote JDBC (exemple : base de données Cloudscape), la sécurité est généralement assurée par la définition d'autorisations d'accès aux fichiers (comme indiqué au paragraphe "Banque permanente intégrée" ci-avant) au niveau du répertoire dans lequel les données permanentes sont stockées. Pour s'assurer que la base de données est accessible en lecture et en écriture à la fois par le courtier et par l'utilitaire imqdbmgr, les deux attributs doivent être exécutés par le même utilisateur.

Configuration de la mémoire du courtier

Lorsque le courtier a quasiment épuisé le segment de mémoire JVM réservé aux objets Java, il a recours à diverses techniques (comme le contrôle de flux et le basculement de messages) pour libérer de la mémoire. Dans des cas extrêmes, il peut même mettre fin aux connexions client pour libérer de la mémoire et réduire l'afflux de messages. Pour éviter d'en arriver là, il est préférable de spécifier un segment de mémoire JVM suffisant.

Par contre, si le segment de mémoire Java maximal est trop élevé, en fonction de la mémoire physique du système, le courtier peut continuer à augmenter la taille du segment mémoire Java jusqu'à épuisement de la mémoire du système. Cette opération peut réduire les performances, provoquer des arrêts brutaux et imprévisibles du courtier et/ou affecter le comportement d'autres applications et services du système.

Ce problème peut être évité en spécifiant une limite de taille de segment de mémoire Java raisonnable, par l'intermédiaire de l'argument de ligne de commande Java -Xmx. Il est conseillé en général d'évaluer les besoins en mémoire, tant normaux que maximum, et de configurer en conséquence la taille du segment de mémoire Java. Elle doit être suffisamment importante pour garantir des performances optimales, mais non surestimée pour éviter les problèmes avec la mémoire système.

Erreurs de saturation de mémoire vis-à-vis du client

Si vous exécutez un client JMS qui traite des messages de taille importante ou de nombreux messages de petite taille, il peut rencontrer des erreurs OutOfMemoryError. L'exécution du client n'a pas de problème de fuite de mémoire, mais il manque juste de mémoire pour copier les messages hors du réseau et les remettre au client.

Pour éviter ces erreurs OutofMemoryError, augmentez la taille du segment de mémoire Java maximale. Pour ce faire, indiquez l'option adéquate au niveau de la commande java ou jre.

Avec Java2, utilisez l'option -Xmx lors de l'exécution de l'application cliente. Par exemple :

Veuillez tenir compte des restrictions suivantes :

Comment signaler les problèmes

Pour signaler un problème, envoyez un courrier électronique à l'adresse imq-feedback@sun.com.

Si vous bénéficiez d'un contrat d'assistance MQ, contactez l'assistance client Sun ONE en utilisant une des méthodes suivantes :

Afin de vous aider à résoudre votre problème, pensez à réunir les informations suivantes lorsque vous contactez l'assistance technique :

Pour plus d'informations

Outre la documentation de MQ, vous disposez des ressources d'information suivantes :

Forums de discussion

Forum des logiciels Sun ONE

Il existe un forum Sun ONE MQ à l'emplacement suivant :

Forum sur la technologie Java

Il existe un forum JMS au sein des forums sur la technologie Java qui peut être utile.

Sun attend vos commentaires

Afin d'améliorer sa documentation, Sun vous encourage à faire des commentaires et à apporter des suggestions. Envoyez vos commentaires à Sun à l'adresse électronique suivante :

Veuillez indiquer le numéro de document (817-3826-10) dans la zone Objet et le titre du manuel (Notes de mise à jour de Message Queue 3.0.1 ) dans le corps du message.

Ressources Sun supplémentaires

Vous pouvez obtenir des informations utiles concernant Sun ONE sur les sites Internet suivants :

Copyright © 2003 Sun Microsystems, Inc. Tous droits réservés.

Sun, Sun Microsystems, le logo Sun, Solaris, Java et le logo Java Coffee Cup, JDBC et JDBC Compliant sont des marques ou des marques déposées de SunMicrosystems, Inc. aux États-Unis et dans d'autres pays. L'utilisation de Sun ONE Message Queue est soumise aux conditions énoncées dans le contrat de licence associé.