Author |
Message
|
gauravagarwal26 |
Posted: Mon Jun 15, 2009 9:29 am Post subject: MQJMS Client Working Bind Not Working |
|
|
Newbie
Joined: 15 Jun 2009 Posts: 8
|
Hello,
I have a Queue Manager QTIBDV01.
I have defined two QueueConnectionFactory
InitCtx> dis QCF(QCF)
MSGRETENTION(YES)
QMANAGER(QTIBDV01)
TARGCLIENTMATCHING(YES)
TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
USECONNPOOLING(YES)
POLLINGINT(5000)
RESCANINT(5000)
TRANSPORT(BIND)
TEMPQPREFIX()
SYNCPOINTALLGETS(NO)
MAPNAMESTYLE(STANDARD)
CONNOPT(STANDARD)
VERSION(6)
MSGBATCHSZ(10)
FAILIFQUIESCE(YES)
InitCtx> dis QCF(QCFCLINT)
MSGRETENTION(YES)
QMANAGER(QTIBDV01)
TARGCLIENTMATCHING(YES)
SSLRESETCOUNT(0)
TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
USECONNPOOLING(YES)
POLLINGINT(5000)
RESCANINT(5000)
TRANSPORT(CLIENT)
HOSTNAME(localhost)
TEMPQPREFIX()
CHANNEL(SYSTEM.DEF.SVRCONN)
SYNCPOINTALLGETS(NO)
MAPNAMESTYLE(STANDARD)
CCSID(819)
CONNOPT(STANDARD)
SSLFIPSREQUIRED(NO)
PORT(1414)
VERSION(6)
MSGBATCHSZ(10)
FAILIFQUIESCE(YES)
The java application(ofcourse it is on the same machine as the queue manager) when connecting to the QueueConnectionFactory QCFCLINT works but it givens the below error when connecting to QCF.
caused by: javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'QTIBDV01'
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:644)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2567)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1912)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:161)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:192)
at com.tibco.pe.PEMain.main(PEMain.java:122)
linked JMS exception: com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2059
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:282)
at com.ibm.mq.MQBindingsManagedConnectionFactoryJ11._createManagedConnection(MQBindingsManagedConnectionFactoryJ11.java:186)
at com.ibm.mq.MQBindingsManagedConnectionFactoryJ11.createManagedConnection(MQBindingsManagedConnectionFactoryJ11.java:225)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:84)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:173)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:795)
Please help. My OS is HP-UX.
Gaurav |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Mon Jun 15, 2009 11:35 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
From your error trace you have an MQ error code of 2059. Have a search of this forum for clues..... |
|
Back to top |
|
 |
gauravagarwal26 |
Posted: Mon Jun 15, 2009 11:49 pm Post subject: |
|
|
Newbie
Joined: 15 Jun 2009 Posts: 8
|
RC 2059 is Queue Manager no available, but that is not possible as I am able to make the client connection.
I have dug around in various forums but could not figure out.
One more thing to consider, the user which is running this java program is different from mqm user. Will it make a difference? What access will this user require to make a bind connection? |
|
Back to top |
|
 |
betterchoices |
Posted: Tue Jun 16, 2009 12:10 am Post subject: |
|
|
Novice
Joined: 08 Jun 2009 Posts: 18
|
I beleive adding would solve the issue..add user to mqm group |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 12:11 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
gauravagarwal26 wrote: |
RC 2059 is Queue Manager no available, but that is not possible as I am able to make the client connection. |
No you have not made a client connection - your attempt ended with a 2059. You might have established a client connection to the queue manager in question successfully from other sources, but not using the configuration you've posted here. Because the configuration you've posted here throws a 2059.
gauravagarwal26 wrote: |
One more thing to consider, the user which is running this java program is different from mqm user. Will it make a difference? |
Well yes, kinda! It's a bit like the difference you get logging on to any system as 2 different users.
gauravagarwal26 wrote: |
What access will this user require to make a bind connection? |
To make either a binding connection or a client connection (as you seem to be trying here) the user id supplied to the queue manager will need connect authority on the queue manager, as well as relevant permissions on the queue objects they subsequently access. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 12:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
betterchoices wrote: |
I beleive adding would solve the issue..add user to mqm group |
It would solve the issue by giving the user in question full administrative authority over the queue manager, and potentially any queue manager attached to it!
This is a concept many auditors & security people have a problem with, and is likely to result in a lot of rather tense conversations. No application should run with mqm authority!
It's much like solving the problem of user management on Windows by getting all the users to sign in as domain Administrator. You certainly spend less time setting up users and file permissions......  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
gauravagarwal26 |
Posted: Tue Jun 16, 2009 12:23 am Post subject: |
|
|
Newbie
Joined: 15 Jun 2009 Posts: 8
|
@Poobah.
AS I mentioned in my original post, I am able to make the client connection using a different queueconnectionfactory.
When I use a queueconnectionfactory with transport as BIND I am getting a 2059.
The user I am talking about here is the user who is executing the java program. I am passing the same credentials in my java program for both client and bind connections.
Ihave tested the IVTRun with jndi and which works without any issues when run with user mqm.
-Gaurav |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 12:32 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
gauravagarwal26 wrote: |
AS I mentioned in my original post, I am able to make the client connection using a different queueconnectionfactory. |
And I never disputed this.
gauravagarwal26 wrote: |
The user I am talking about here is the user who is executing the java program. I am passing the same credentials in my java program for both client and bind connections. |
I would be surprised to discover you got a 2059 from a security issue (rather than a 2035), but I'm constantly surprised about Java. It's simple enough to prove though; explicitly authorise the user in question (or his group) to connect and retry to see if the 2059 resolves. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
betterchoices |
Posted: Tue Jun 16, 2009 12:33 am Post subject: |
|
|
Novice
Joined: 08 Jun 2009 Posts: 18
|
Vitor, I understand your concern, and what you are saying should be done.
Actually I was also, authority issue when my application tried to pick messages, I added it to mqm group and it worked. I was on client site, and there was no other immediate sol.
Previous to client mode, i tried bind mode. In my case client program was a MDB deployed on OC4J server, it was impossible to pick messages from MQ, when client program was on different machine. Because some mq dll's were required at runtime. Even when my cleint application was deployed on same machine, it was unable to pick MQ dll's to connect. This was a OC4j issue. Setting path didn't worked. I had to manually copy required dll'e to system 32, then application was able to pick those dll's, and able to connect to MQ.
I would never use bindings mode again, I used Client mode, it worked on same system, but when on different system, cleint application was unable to pick. it was giving some authority issues. I added cleint machine to mqm group, and problem was solved.
I know this is not good solution, but for my it worked. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 12:40 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
betterchoices wrote: |
I added it to mqm group and it worked |
As I indicated, this will fix most WMQ security issues at a stroke.
betterchoices wrote: |
I was on client site, and there was no other immediate sol. |
Given that you had the ability to add users to the mqm group, at least one other solution was open to you. A much better one. Use mqm authority to grant connect and other authorities to fix the problem.
betterchoices wrote: |
I added cleint machine to mqm group, and problem was solved. I know this is not good solution, but for my it worked. |
I didn't say it didn't work. What I said was you left your client system wide open to anybody with less than honest intent, or above average incompetance and the client's auditors will not be happy with the situation. This tends to end badly. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
gauravagarwal26 |
Posted: Tue Jun 16, 2009 3:08 am Post subject: |
|
|
Newbie
Joined: 15 Jun 2009 Posts: 8
|
so I added this user ipesvdev which is executing the java program to mqm group but it still gives the same error. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 3:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
gauravagarwal26 wrote: |
so I added this user ipesvdev which is executing the java program to mqm group but it still gives the same error. |
Vitor wrote: |
I would be surprised to discover you got a 2059 from a security issue (rather than a 2035) |
I feel vindicated.
So it's not a security problem but a more "usual" 2059 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
gauravagarwal26 |
Posted: Tue Jun 16, 2009 6:27 am Post subject: |
|
|
Newbie
Joined: 15 Jun 2009 Posts: 8
|
I can connect to the same queue manager from the same java code on the same machine using a client transport as mentioned in my original post.
What different configuration is required to run it on BIND transport. |
|
Back to top |
|
 |
betterchoices |
Posted: Tue Jun 16, 2009 6:44 am Post subject: |
|
|
Novice
Joined: 08 Jun 2009 Posts: 18
|
hi gaurav..
i had a very complicated applicaiton listening to MQ. application was a MDb deployed on oc4j.. i remember i first tried bindings mode, then i switched to client mode.
Problem with bindings mode was that oc4j needed some dll's mainly IBM\WebSphere MQ\java\lib\mqjbnd.dll. and some more dll's on whaich this dll depends.
Ok in my case oc4j was unable to find these dll's... what i know when u run application from cmd. you can use -Djava.libraray.path.. to set the JNI path i.e. to mqjbnd.dll path.. the your application would be successfully connected to MQ...
In my case this was not sufficient,s o i had to manuallly copy this and other dll's to C:\windows\system32 path... |
|
Back to top |
|
 |
betterchoices |
Posted: Tue Jun 16, 2009 6:51 am Post subject: |
|
|
Novice
Joined: 08 Jun 2009 Posts: 18
|
When we are using bindings mode to connect to MQ, we need to modify the library path i.e. include mq dll's into the java library path.
we can use command like this
java -Djava.library.path=C:\Program Files\IBM\WebSphere MQ\java\lib;C:\Program Files\IBM\WebSphere MQ\bin application.java
C:\Program Files\IBM\WebSphere MQ is the path, where MQ is installed on my machine.
application.java is my application which connects to MQ.
And transaport mode of Queue is Bindings.
I believe this would work. Please try this.
Well, gaurav you can also set the env variables to include dll'd located in these( MQ ) path permanently. |
|
Back to top |
|
 |
|