MQ avec serveur étranger WLS

Question

Je suis confronté à deux problèmes lorsque j'essaie de me connecter à MQ qui est déployé sur un serveur distant à partir de Weblogic Server (WLS) en créant un serveur étranger. 1. Lorsque j'essaie de me connecter à MQ Queuemanager en mode Bindings (après avoir importé le fichier .Bindings), je continue à obtenir l'erreur suivante dans la console WLS :

java.lang.UnsatisfiedLinkError : pas de mqjbnd05 dans java.library.path

2. Si je change le Transport en Client, je continue à obtenir :

JMSWMQ0018 : Failed to connect to queue manager '' with connection mode 'Client' and host name 'localhost'. Vérifiez que le gestionnaire de file d'attente est lancé et, s'il fonctionne en mode client, vérifiez qu'un listener est en cours d'exécution. Veuillez consulter l'exception liée pour plus d'informations.

Est-ce que quelqu'un a vu cela, et y a-t-il des implications de performance qui dictent l'utilisation du client sur les liaisons et vice versa ?

TIA

Answer 1

Lorsque la question indique que J'essaie de me connecter à MQ qui est déployé sur un serveur distant à partir du serveur Weblogic. Je suppose que cela signifie que WLS et WMQ se trouvent sur deux hôtes différents. Si c'est le cas, alors une connexion en mode bindings (qui repose sur des segments de mémoire partagée) ne fonctionnera pas.

La connexion en mode client semble utiliser un CF qui pointe vers localhost plutôt que vers l'IP ou le nom d'hôte du serveur WMQ. Cela fonctionnerait pour une application située sur le même hôte que le gestionnaire de files d'attente, mais pas lorsque l'application et QMgr se trouvent sur des serveurs distincts.

En ce qui concerne le choix entre le mode client et le mode bindings, la réponse est que si le QMgr est local, utilisez les bindings. Cela offre la plus grande fiabilité, les meilleures performances et la transactionnalité XA. Lorsque vous utilisez le mode client, le commit XA à deux phases n'est pas pris en charge sans le client transactionnel étendu. Selon la spécification JMS, il y a une ambiguïté qui peut exister si une application perd la connexion pendant un appel COMMIT. Selon la façon dont l'application gère cette situation, il est possible de se retrouver avec des messages en double. (La spécification JMS fait référence à ces messages comme étant "fonctionnellement dupliqués"). beaucoup Il est moins probable que cela se produise avec une connexion en mode bindings puisqu'il n'y a pas de latence du réseau ni même de traversée de la pile ou de l'interface IP. Utilisez donc le mode bindings lorsque cela est possible.

UPDATE :
Suppression de la note sur le fait que le client transactionnel étendu est un composant facturable. A partir du 24 avril XTC est gratuit pour toutes les versions de WMQ sur toutes les plateformes.

Answer 2

J'ai finalement pu résoudre ce problème, j'ai dû recréer le fichier .bindings en mode client, en modifiant le fichier IVTsetup.bat qui se trouve probablement dans le dossier C:\Program Fichiers \IBM\WebSphere MQ \java\bin j'ai dû exécuter ceci def qcf(psQCF) TRANSPORT(CLIENT) HOST(SMEKA) PORT(1415) CHANNEL(ps_SRV_CHANNEL) QMGR(psQM) pour générer le fichier .bindings.

Consultez ce lien pour plus de détails :

http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_adapters.doc/doc/peoplesoft/peopleso103.htm