Cette section contient une liste des problèmes connus concernant Message Queue 3.7 UR1. Elle aborde plus particulièrement les questions suivantes :
Pour obtenir une liste des bogues actuels, leur état et leurs solutions, les membres de Java Developer Connection™ peuvent consulter la page Bug Parade du site Web de Java Developer Connection. Avant de signaler tout nouveau bogue, merci de consulter cette page. Bien que tous les bogues de Message Queue n'y soient pas répertoriés, il est préférable ce consulter cette page pour savoir si un problème a déjà été signalé.
http://bugs.sun.com/bugdatabase/index.jsp
L'adhésion à Java Developer Connection est gratuite, mais elle requiert une inscription. Pour savoir comment devenir membre de Java Developer Connection, consultez la page Web « For Developers » de Sun .
Pour signaler un nouveau bogue ou soumettre une demande d'amélioration, envoyez un e-mail à l'adresse suivante : imq-feedback@sun.com .
Un service de connexion utilisant SSL ne peut actuellement prendre en charge que des certificats de serveur autosignés, c'est-à-dire, en mode hôte de confiance.
Lorsqu'un client JMS utilisant le transport HTTP met brutalement fin à la connexion(en utilisant, par exemple, Ctrl-C), le courtier met environ une minute avant de libérer la connexion client et toutes les ressources associées.
Si une autre instance du client est démarrée dans la minute d'attente en essayant d'utiliser le même ID client, la même souscription durable ou file d'attente, il est possible que celle-ci reçoive une exception « L'ID client est déjà utilisé ». Il ne s' agit pas d'un vrai problème, mais d'un effet secondaire du processus de fin décrit précédemment. Si un client est démarré après un délai d' environ une minute, tout doit fonctionner correctement.
Dans Message Queue 3.7 UR1, la configuration de courtier modèle pour utiliser un serveur LDAP comme référentiel utilisateur est proposée dans la zone de commentaires du fichier config.properties, alors que le modèle de référentiel utilisateur LDAP du fichier default.properties a été supprimé des commentaires.
Si vous dépendiez auparavant des valeurs de propriétés de la configuration du référentiel utilisateur LDAP donné en exemple dans le fichier default.properties, votre client d'application JMS recevra une exception de sécurité lorsqu'il tentera de créer une connexion JMS. Cela se produira après la mise à niveau de Message Queue 3.7 UR1.
Lorsque le client JMS tente d'établir une connexion avec le courtier de Message Queue 3.7 UR1, une erreur s'affiche dans le journal du courtier et le client JMS reçoit l'exception suivante :
SecurityException. 20/Aug/2004:11:16:41 PDT] ERROR [B4064]: propriété LDAP du référentiel LDAP .uidattr non définie pour le type d'authentification basic:com.sun.messaging.jmq.auth.LoginException: [B4064]: propriété LDAP du référentiel LDAP .uidattr non définie pour le type d'authentification basic
Solution : définissez la propriété du courtier imq.user_repository.ldap.uidattr en suivant les instructions du Chapitre 7, Managing Security du Sun Java System Message Queue 3.7 UR1 Administration Guide.
Les éléments suivants décrivent l'utilisation des clusters de courtier.
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 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.
Si aucun courtier ne fait office de courtier principal dans un cluster, les informations permanentes enregistrées par un courtier ayant été ajouté au cluster ne sont pas communiquées aux autres courtiers du cluster.
La connexion est abandonnée pour un courtier dans un cluster (ID de bogue 6377527).
Une des explications possibles est que l'adresse du courtier (dont la connexion a été abandonnée) correspond à l'adresse IP du loopback (127.0.0.1).
Solution : assurez-vous que l'adresse du courtier ne correspond pas à l'adresse IP du loopback.
Dans un cluster de courtier, un courtier mettra en file d'attente les messages destinés à une connexion distante non démarrée (ID de 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.
Les problèmes suivants se rapportent à l'administration et la configuration de Message Queue.
Les utilitaires imqadmin et imqobjmgr émettent une erreur lorsque CLASSPATH contient des guillemets sur des machines Windows (ID de bogue 5060769)
Solution : vous pouvez ignorer ce message d'erreur, le courtier traite correctement le problème en notifiant toute erreur aux consommateurs. Cette erreur n'affecte pas la fiabilité du système.
L'option -javahome dans tous les scripts Solaris et Windows ne fonctionne pas si la valeur fournie contient un espace (ID de bogue 4683029).
L'option javahome est utilisée par les commandes et utilitaires de Message Queue pour spécifier une autre exécution Java 2 compatible à utiliser. Cependant, le nom de chemin vers l'exécution Java alternative ne doit pas contenir d'espace. Voici quelques exemples de chemins contenant des espaces :
sous Windows : C:/jdk 1.4
Solaris : /work/java 1.4
Solution : installez le programme d'exécution Java à un emplacement ou un chemin ne contenant pas d'espace.
L'attribut imqQueueBrowserMaxMessagesPerRetrieve spécifie le nombre maximal de messages que le programme client récupère en une fois lorsqu'il parcourt le contenu d'une destination en file d'attente. Notez que l'application cliente obtient toujours tous les messages de la file d'attente. Ainsi, l'attribut imqQueueBrowserMaxMessagesPerRetrieve affecte le mode de segmentation des messages en file d'attente, qui doivent être envoyés vers le programme client (quelques blocs volumineux ou plus de blocs plus petits), mais n'affecte pas le nombre total de messages parcourus. Modifier la valeur de cet attribut pourrait avoir un impact sur les performances mais aucun effet sur le volume de données traité par l'application cliente (ID de bogue 6387631).
Les problèmes suivants concernent le courtier de Message Queue.
La commande imqbrokerd —license affiche des informations obsolètes ou dupliquées. Elle affiche des informations relatives à la licence d'essai, bien que ce type de licence ne soit plus pris en charge (ID de bogue 6489711) ainsi que des informations dupliquées concernant la licence unl (ID de bogue 6441015).
Solution : il s'agit de problèmes esthétiques qui ne requièrent pas de solution.
Le courtier ne respecte pas la limite par défaut de 1000 messages pour la file d'attente des messages bloqués ; il continue d'ajouter des messages dans la file d'attente des messages bloqués jusqu'à ce qu'il n'y ait plus assez de mémoire. (ID de bogue 6502744)
Solution : réinitialisez la limite de la file d'attente des messages bloqués sur 1001 ou toute valeur supérieure à 1000.
La createQueueConnection HTTPS émet occasionnellement une exception sur Windows 2000. (ID de bogue 4953348).
Solution : réessayez la connexion.
Avec Ctrl-C pour fermer le courtier, les transactions peuvent être nettoyées après fermeture du magasin (ID de bogue 4934446).
Le courtier peut afficher des erreurs pour la raison suivante : « Tentative d'accès à la méthode de stockage après fermeture du magasin. » si le courtier est fermé alors que les messages ou les transactions sont en cours de traitement.
Solution : vous pouvez ignorer ce message d'erreur, le courtier traite correctement le problème en notifiant toute erreur aux consommateurs. Cette erreur n'affecte pas la fiabilité du système.
Le courtier devient inaccessible lorsque le magasin persistant ouvre trop de destinations. (ID de bogue 4953354).
Solution : ce problème est dû au fait que le courtier atteint la limite du descripteur de fichier ouvert définie pour le système. Sur Solaris et Linux, utilisez la commande ulimit pour augmenter cette limite.
Les consommateurs sont orphelins lorsqu'une destination est supprimée (ID de bogue 5060787).
Les consommateurs actifs sont orphelins lorsqu'une destination est supprimée. Une fois orphelins, ils ne peuvent plus recevoir de messages (même si la destination est recréée).
Solution : il n'existe aucune solution pour ce problème.
La sélection de messages à l'aide de JMSMessageID ne fonctionne pas (ID de bogue 6196233).
Solution : modifiez le sélecteur de l'expression
JMSMessageID = "ID:message-id-string"
à l'expression
JMSMessageID IN (’ID:message-id-string’, ’message-id-string’)
Le navigateur de file d'attente A de Message Queue affiche des messages non dédiés (ID de bogue 6264003).
Lors de la navigation dans le contenu d'une file d'attente, les messages produits dans une transaction mais non encore dédiés apparaissent dans l'énumération du navigateur de file d'attente.
Solution : il n'existe aucune solution pour ce problème.
Des messages peuvent devenir indisponibles si le courtier s'arrête brutalement pendant une validation (ID de bogue 6467874).
Rarement, lors d'un arrêt brutal, les messages dans une transaction peuvent devenir indisponibles pour les clients. Spécifiquement, une petite fenêtre apparaît pendant le processus de validation et peut provoquer un blocage du message dans le magasin persistant. Lorsque cela se produit, le message suivant s'affiche au démarrage du courtier après un arrêt brutal.
[06/Sep/2006:10:11:11 PDT] ERROR [B2085]: Loading Destination q0 [Queue] failed. Messages stored on that destination will not be available.: > com.sun.messaging.jmq.jmsserver.util.BrokerException: The message 8-129.145.180.87(b8:8b:26:15:41:26)-38998-1157562551217 has an associated acknowledgement list already.
Solution : il n'existe aucune solution pour ce problème.
Il n'existe pas de produit autonome pour la version Bêta de Message Queue 3.7 UR1. Pour cette version, vous devez donc installer Message Queue à l'aide du programme d'installation de Java Enterprise System. Reportez-vous au Sun Java System Installation Guide pour obtenir les instructions correspondantes.