|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Issue with JMS Bindings |
« View previous topic :: View next topic » |
Author |
Message
|
abdul.mbr |
Posted: Fri Aug 19, 2011 9:40 am Post subject: Issue with JMS Bindings |
|
|
Newbie
Joined: 19 Aug 2011 Posts: 8
|
Hello guys,
I am having some issue with connecting to a queue on a queue mananger using JMS bindings. I am getting the following error
WARNING: JMS exception.
Throwable occurred: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MQXISGC2' with connection mode 'Bindings' and host name (2190)'. Please check if the supplied username and password are correct on the QueueManager you are connecting to
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:540)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:448)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:7160)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:6551)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:295)
at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6232)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:115)
at com.deere.u90785.ex.cs.mq.CSMQConnectionManager.createQueueConnection(CSMQConnectionManager.java:66)
at com.deere.u90785.ex.cs.mq.MQManager.sendToInternalComms(MQManager.java:40)
at com.deere.u90785.ex.cs.mq.MQManager.sendToInternalComms(MQManager.java:22)
at com.deere.u90785.ex.cs.smtp.SMTPSession.writeToQueue(SMTPSession.java:171)
at com.deere.u90785.ex.cs.smtp.SMTPSession.run(SMTPSession.java:83)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:898)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:920)
at java.lang.Thread.run(Thread.java:736)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
at com.ibm.mq.MQException.<init>(MQException.java:1411)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:200)
I know it has to do with the userid used to access the queues. But how can i findout which userid i am using and change the userid to something which has access ot the queue like say mqm or mquser.
I am also not sure abt the username and password mentioned in the error log.
Please help me out. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Aug 19, 2011 10:03 am Post subject: Re: Issue with JMS Bindings |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
abdul.mbr wrote: |
But how can i findout which userid i am using and change the userid to something which has access ot the queue like say mqm or mquser. |
First point - no application should ever use mqm or any administrative id to access the queue manager unless you want your developers to have the same administrative control as you.
Second point - how do you find out the user id any Java application is using? Do that here. Then check to see if WMQ is overriding it (which would be part of the configuration you're administering).
Third point - do not change the application to use mqm. Either authorise the user id the application is using in WMQ, or supply them with a non-mqm id to use.
Fourth point - get some training. This is basic, basic stuff.
abdul.mbr wrote: |
I am also not sure abt the username and password mentioned in the error log. |
That's a standard JMS error. WMQ does not authenticate with a password, it authorises with a user id. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
balaji83it |
Posted: Thu Aug 25, 2011 3:36 am Post subject: |
|
|
Acolyte
Joined: 20 Jul 2007 Posts: 72
|
Hello Abdul,
You can add the following line in your mqm user profile and see the Qmgr logs which user is trying to access.
export MQS_REPORT_NOAUTH=TRUE
Once you know the user, give appropriate permissions to it and you should not be facing the issue again.
Regards,
Balaji. |
|
Back to top |
|
 |
exerk |
Posted: Thu Aug 25, 2011 4:08 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
balaji83it wrote: |
Hello Abdul,
You can add the following line in your mqm user profile and see the Qmgr logs which user is trying to access.
export MQS_REPORT_NOAUTH=TRUE
Once you know the user, give appropriate permissions to it and you should not be facing the issue again.
Regards,
Balaji. |
And restart the queue manager... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|