JMS Message Bridge - WLS to MQ

Question

Hi,
Subsequent to my last posts on Foreign JMS Server setup (where I had to receive a msg from a remote MQ Queue), now I have a requirement to post messages to an remote MQ Queue for a diff application.
As a POC, I configured the JMS Message Bridge with bridge source as my local JMS queue and bridge destination as the Remote MQ Queue and it works fine as expected !!
just have couple of questions on that -
1. For a long time, I was struggling with this error on server startup
<BEA-190032> << eis/jms/WLSConnectionFactoryJNDINoTX > ResourceAllocationException thrown by resource adapter on call to ManagedConnectionFactory.createManagedConnection(): "javax.resource.ResourceException: Failed to start the connection ">
Then I realized from the server log that the actual reason was authentication failure in MQ Queue Manager :
JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager '' with connection mode 'Client' and host name '77.40.190.130'. Please check if the supplied username and password are correct on the QueueManager you are connecting to AND
JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
Since this MQ setup is managed by someone else, when they pass on the .binding file after creating queuemanager, queue, etc, Should I also ask them for the username and password for the QM?? I am not sure if this is a part of the .binding file.
2. Some doubts around the QOS. As I understood, I am using the No-Transaction Adapter. This means I can use QOS as either "Atmost once" or "Duplicate OK". The latter seems to be ok so that I dont lost messages in any case. But I am yet to find out if the other application is ok to handle duplicates.
But is there a restriction/limitation to use "Exactly Once" ?? I noticed that there is also an XA-Transaction Adapter in WLS. Is it not possible to use that with MQ?
Thanks in advance.
best regards,
Murali

Answer 1

In your binding file QCF or XAQCF definition , you will see a Channel field since you are using a client mode to connect to the queue manager. This channel is called a Server Connection Channel [ SVRCONN]. At the queue manager side of things, when this SVRCONN is defined, MQ Admin teams tend to define an attribute called MCAUSER. In this setup the userid used for authorisation at queue manager is the following in the below precedence:
1. If MCAUSER is defined in the channel, that will be the user id and it overrides any security context sent from client application. This user id should have sufficient permissions to connect to queue manager , get , put. The MQ admin teams on certain platforms will be able to get the exact permission that is missed from the queue manager error logs when a 2035 security exception occurs.
2. If no MCAUSER is defined then the userid passed in the createConnection JMS call will be the user context used.
I am not exactly sure of the behaviour when no MCAUSER and no user id in createConnection calls, but i think it takes the user of the MQ Listener process which starts the SVRCONN channel instance when a client initiates the connection.
So for your situation, it will be worth start checking with how the MQ side configuration is. This issue tends to be a very common issue with client applns connecting to qmgr.