J'utilise MQ7 et j'essaie d'accéder à une file d'attente avec JMS API. Obtenir cette erreur. Quelqu'un a-t-il déjà vu? comment résoudre ça? TIA
Exception dans le thread "Main" com.ibm.msg.client.jms.detailedjmSException: JMSFMQ6312: Une exception est survenue dans le MQI Java (TM). Le Java (TM) MQI a lancé une exception décrivant le problème. Voir l'exception liée pour plus d'informations.
causée par: com.ibm.mq.jmqi.jmqiexception: CC = 2; RC = 2495; AMQ8568: La bibliothèque JNI natif 'MQJBND' n'a pas été trouvée. [3 = mqjbnd]
causée par: java.lang.unsatisfiedlinkerror: no mqjbnd en java.library.path
6 Réponses :
Ceci est presque toujours causé par une combinaison d'une installation incomplète du client et / ou d'un problème de classe de classe. Beaucoup de gens saisissent les fichiers JAR plutôt que d'effectuer l'installation complète et ne les obtiennent pas nécessairement. En plus d'assurer que tous les fichiers binaires requis sont présents, l'utilisation du support d'installation fournit plusieurs capacités supplémentaires telles que le diagnostic et la trace. Il assure également que la maintenance peut être appliquée. Les supports d'installation du client WMQ sont disponibles gratuitement en tant que supportPac MQC7 . Le réglage de classe doit être tel que décrit dans le WebSphere MQ à l'aide du manuel Java .
Si l'installation du client est effectuée à partir du support IBM et que l'environnement est configuré selon les documents, cela corrige presque tous les cas tels que vous avez signalé ici. Il existe quelques applications de test de vérification d'installation (certaines de ces diagnostics installés avec le support complet que j'ai mentionné) décrit ici et qui peut aider à déterminer si un problème est avec l'installation ou le code.
Le scénario est que j'utilise un programme Java pour accéder à une file d'attente MQ déployée sur une machine distincte via JMS. J'ai donc toutes les libs MQ requis du serveur, l'étrangeté réside dans le fait que le même programme fonctionne parfaitement sur le serveur. Où MQ est déployé avec les mêmes pots dans la classe de classe, peut-être que cela a quelque chose à voir avec Java.Library.Path Prop, plus d'idées. :)
Le message d'erreur indique clairement que Java.Library.Path est manquant MQJBND. Si vous allez sur le serveur sur lequel cela fonctionne, je suis sûr que vous constaterez que sa java.library.Path est correctement définie. Vous faire la même chose et ça marchera, je suis sûr.
C'est la raison pour laquelle IBM ne prend pas en charge ce type d'installation. Si vous utilisez le support de support MQC7 pour installer le client, vous obtenez tous les libs et les pots requis ainsi que les utilitaires de diagnostic. Selon votre commentaire, le seul endroit où le support d'installation a été utilisé, cela fonctionne. Pourquoi ne pas utiliser la procédure documentée et prise en charge pour installer les Libs clients? Ensuite, vous pourriez ouvrir les PMR si nécessaire et appliquer la maintenance. Ou sont ces choses qui ne sont pas importantes pour votre application?
Cela fonctionne lorsque le client et le serveur résident dans la même machine, mais pas dans SPÉLA
Ou de mon point de vue, cela fonctionne sur la machine dans laquelle l'installation d'installation d'IBM était exécutée et non sur la machine où les pots ont été installés en les copiant. En tant que consultant IBM spécialisé dans WMQ, je le vois beaucoup. La première chose que je reçois mes clients à faire est de gérer l'installation prise en charge selon la documentation. Cela fixe 80% ~ 90% des problèmes tels que vous rapportez. Si vous ne souhaitez pas exécuter le support d'installation sur la machine client, je ne peux plus vous aider. Si cela ne fonctionne toujours pas avec l'installation complète, je demanderais à voir la sortie du programme de test de vérification initial.
Je l'ai installé à l'aide du processus mentionné dans le manuel IBM Chapitre 3 "Installation d'un client WebSphere MQ", sur Linux 64 Bit. Le commandement suivant me donne ce résultat. DSPMQVER -P 63 Nom: WebSphere MQ Version: 7.0.1.6 Niveau CMVC: P701-106-110725 BUILDTYPE: IKAP - (production). . . Nom: IBM WebSphere MQ Version: 7.0.1.6 CMVC Niveau: K701-106-110721 MQJBND = CC = 2; RC = 2495; AMQ8568: La bibliothèque JNI natif 'MQJBND' n'a pas été trouvée. [3 = MQJBND] :: NON MQJBND EN JAVA.LIBRARY.PATH Type de construction: Production Disthub Build Niveau: HUB Distribution de Webscale DH610-Gold
@ T.ROB HI, pouvez-vous corriger le lien "Il existe quelques applications de test de vérification d'installation ..."? Merci ;-)
@Betlista peut-être que le serveur était en panne? Le lien fonctionne pour moi maintenant. Cependant, c'est pour v7.0 et donc voici un article actuel: Configuration postale d'installation pour les classes WebSphere MQ pour applications JMS - V7.5
Merci, de nouveaux liens fonctionnent bien, tandis que le précédent qui ne fonctionne toujours pas (la page vide indique ici en Europe), 7.5 est meilleur de toute façon ;-) J'ai trouvé celui-ci ( www-01.ibm.com/support/docview.wss?uid=swg21413508 ) vraiment utile, mais cela ne fonctionne de toute façon pas: - (toutes les propriétés sont configurées, mais dspmqver.exe montre "la bibliothèque de JNI natif"? "N'a pas trouvé" "Je n'ai pas trouvé de bonne étape par étape Tutorial Comment faire des échantillons ...
Vous devrez peut-être effacer les cookies. L'infocentre se présente également en blanc pour moi aussi, mais quand je dégage des biscuits (et parfois cache), il revient tout de suite. Notez que les infecentres sont servis à partir de différents sites IBM commençant par V7.5 afin qu'il se comporte différemment. Pour le moment, j'ai accès aux quatre infeceneurs de V6.0 à V7.5. DERNIÈRE Firefox, Win 7x64, Noscript, USA IP Addy.
Avez-vous fait SETMQINST Après l'installation?
@ T.ROB Après avoir exécuté SetMqinst, il m'a dit de redémarrer PC, ce que je n'avais probablement pas précédemment, maintenant le DSPMQver.exe fonctionne. J'ai également constaté que ces liens que je faisais comme ne fonctionne pas ne fonctionne pas dans Chrome, mais ils fonctionnent bien à Firefox.
Le paramètre vm -djava.library.path = / opt / mqm / java / lib64 fonctionne pour moi. Mon environnement est installé à 64 bits avec MQ installé et mon programme utilise le type de transport "liés"
Probablement un peu en retard mais j'avais le même problème et j'ai constaté que cela peut être évité si vous utilisez un mode de connexion différent lors de la connexion à une file d'attente distante. Par défaut, le mqconnectionfactory utilise wmq_cm_bindings comme mode de connexion. Si vous le modifiez à WMQ_CM_CLIENT (ou le mode de connexion que vous aimez, cela ne nécessite pas de bibliothèques indigènes), vous devriez être bien.
Comme quelqu'un se battant aussi avec ce problème, j'aimerais clarifier que la commutation à WMQ_CM_CLIENT est nécessaire mais pas suffisante. J'ai aussi besoin d'inclure "com.ibm.mq.jmqi.jar" dans mon ensemble de pots de bibliothèque. Juste pour info, ceci à son tour tire dans jms.jar, com.ibm.mq.headers.jar et com.ibm.mq.jar. Je vois toujours (d'autres) problèmes, cependant, alors plus de bocaux peuvent être nécessaires.
Acceptez avec Johnnam, c'est arrivé parce que la ConnectiveFactory définit comme serveur par défaut, il doit être défini comme client, vous avez dit qu'il fonctionne sur la même machine. Parce que j'ai également rencontré la même situation, il est exécuté lorsqu'il est exécuté sur la même machine, dans ce cas parce que votre machine est en tant que serveur WMQ, donc le programme, mais lorsque vous exécutez une machine différente, votre programme doit définir comme client.
i Correction. Utilisant défini certains paramètres sur ConnecFactory: P>
<bean id="mqConnectionFactory" class="com.ibm.mq.jms.MQConnectionFactory"> .... <property name="transportType" value="1" /> <property name="clientReconnectTimeout" value="2" /> <property name="clientReconnectOptions" value="0" /> </bean>
Le problème est avec la variable de chemin sur les propriétés du système. Essayez de lancer le code en spécifiant Mqinstallation dir: \ lib64 chemin avant Mqinstallation dir: \ lib
Ajoutez le ci-dessous à vos arguments Tomcat: si le répertoire d'installation est différent de ce qui précède, utilisez l'emplacement approprié.