views:

42

answers:

2

hi, I am facing two issues when i try to connect to MQ which is deployed on a Remote Server from Weblogic Server(WLS) by creating a Foreign Server. 1. When I try to connect to MQ Queuemanager in Bindings mode(after importing the .Bindings file) i keep getting the below error in WLS console:

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

  1. If i Switch the Transport to Client i keep getting:

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.

Has anyone seen this, and are there any performance implications which dictate the use of client over bindings and vice versa?

TIA

+1  A: 

Where the question states that I try to connect to MQ which is deployed on a Remote Server from Weblogic Server I assume this means that WLS and WMQ are on two different hosts. If that is the case, then a bindings mode connection (which relies on shared memory segments) won't work.

The client mode connection appears to be using a CF that is pointed to localhost rather than the IP or hostname of the WMQ server. This would work for an application on the same host as the queue manager but not when the app and QMgr are on separate servers.

As far as choosing between client and bindings mode, the answer is that if the QMgr is local use bindings. This provides highest reliability, best performance and XA transactionality. When using client mode, two-phase XA commit is not supported without the Extended Transactional Client and that incurs a license obligation at the same cost as a QMgr. Per the JMS specification, there is an ambiguity that can exist if an app loses the connection during a COMMIT call. Depending on how the app handles this it's possible to end up with duplicate messages. (The JMS spec refers to these as "functionally duplicate.") This ambiguity is much less likely to occur with a bindings mode connection since there is no network latency and not even any traversal of the IP stack or interface. So use bindings mode where possible.

T.Rob
Hey Rob, Thanks for making sure to reply to my queries, been getting a lot lately, My Client App is also on a separate machine than WMQ. I changed the IP in the bindings file, as foreign server in WLS makes use of the same, is there anywhere else i need to make the change..?
hakish
The default value for the hostname is localhost so there may be a CF in your .bindings file that is simply missing that value. For example, two CF where one has the right hostname, one does not and it's the one without that you are referencing. The JMS classes will only take the value from the CF unless a Client Channel Definition Table (CCDT) is present to override them. That artifact is pointed to in the CF by the CCDTURL property.
T.Rob
By the way, I'm happy to respond to these queries but if you want to make Stack Overflow work better for you, vote up and accept answers. I see you have only a 50% answer rate so either you are asking EXTREMELY hard questions with very few right answers or you are not rewarding responders appropriately. Personally I'll respond whether you vote my answers or not (would be nice) but many folks would hesitate to put much work into an answer for someone with your accept rate.
T.Rob
Sure Rob, point taken.. :)
hakish
Thanks Rob for your comments, they really helped.
hakish
A: 

Finally i was able to resolve this, i had to recreate the .bindings file in the client mode, with changes to the IVTsetup.bat which is most likely present in C:\Program Files\IBM\WebSphere MQ\java\bin, I had to run this def qcf(psQCF) TRANSPORT(CLIENT) HOST(SMEKA) PORT(1415) CHANNEL(ps_SRV_CHANNEL) QMGR(psQM) to generate the .bindings file.

Refer to this link for more details:

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

hakish
My suspicions were correct then. Your CF was pointed to "localhost". Glad to see you got it sorted out.
T.Rob