MQ avec WLS étrangères serveur

Question

Je suis confronté à deux problèmes lorsque je tente de se connecter à MQ qui est déployé sur un serveur distant à partir Weblogic Server (WLS) en créant un serveur étranger. 1. Lorsque je tente de se connecter à MQ QueueManager en mode Liaisons (après avoir importé le fichier .bindings) Je continue à obtenir l'erreur ci-dessous dans la console WLS:

java.lang.UnsatisfiedLinkError: no mqjbnd05 in java.library.path

2. Si i Mettez le transport au client Je continue à obtenir:

JMSWMQ0018: Failed to connect to queue manager '' with connection mode 'Client' and host name 'localhost'. Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.

quelqu'un at-il vu cela, et quels sont les implications sur les performances qui imposent l'utilisation du client sur les liaisons et vice-versa?

TIA

Answer 1

Enfin, j'ai été en mesure de résoudre ce problème, j'ai dû recréer le fichier .bindings en mode client, avec des modifications à l'IVTsetup.bat qui est probablement présent dans C: \ Program Files \ IBM \ WebSphere MQ \ java \ bin, je devais exécuter ce def qcf (psQCF) TRANSPORT (CLIENT) HOST (SMEKA) PORT (1415) CANAL (ps_SRV_CHANNEL) QMGR (PSQM) pour générer le fichier .bindings.

Se reporter à 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

Answer 2

Lorsque la question précise que je tente de se connecter à MQ qui est déployé sur un serveur distant à partir du serveur Weblogic Je suppose que cela signifie que WLS et WMQ sont sur deux hôtes différents. Si tel est le cas, une connexion en mode liaison (qui repose sur des segments de mémoire partagée) ne fonctionnera pas.

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

En ce qui concerne le choix entre le client et le mode de liaisons, la réponse est que si le QMGR est des liaisons d'utilisation locale. Cela fournit la plus haute fiabilité, la meilleure performance et la transactivité XA. Lors de l'utilisation du mode client, la validation XA à deux phases n'est pas prise en charge sans le client transactionnel étendu. Selon la spécification JMS, il existe une ambiguïté qui peut exister si une application perd la connexion lors d'un appel COMMIT. Selon la façon dont l'application gère cela, il est possible de se retrouver avec des messages en double. (La spécification JMS fait référence à ces derniers comme « doublon fonctionnel. ») Cette ambiguïté est beaucoup moins susceptibles de se produire avec une connexion en mode de liaisons car il n'y a pas de temps de latence du réseau et même pas traversal de la pile IP ou de l'interface. Utilisez donc le mode bindings lorsque cela est possible.

MISE À JOUR:
Remarque sur le client Suppression transactionnelles étendue étant un composant charge. As of April 24th, XTC est gratuit pour toutes les versions de WMQ sur toutes les plateformes.