|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
2035 with server bindings |
« View previous topic :: View next topic » |
Author |
Message
|
csaunders |
Posted: Thu Mar 27, 2003 1:03 pm Post subject: 2035 with server bindings |
|
|
Acolyte
Joined: 27 Mar 2003 Posts: 64 Location: Arlington, Va
|
We have multiple applications accessing a qmanager. One of these applications when using jms server bindiing gets 2035, if we switch to client bindings the 203 goes away. The applications are written in java and are using weblogic 6.1 as the apps server. Any sugestions? |
|
Back to top |
|
 |
bduncan |
Posted: Thu Mar 27, 2003 2:07 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
This is a common problem, you might want to try using the search tool and looking for "2035" or "dspmqaut".
You should first use dspmqaut to see if the user that the application is running as has access to the queue manager/queue in question. And if you have used setmqaut to change permissions recently you may need to issue "REFRESH SECURITY" from runmqsc if you are using MQ5.3, otherwise restart the queue manager. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
csaunders |
Posted: Wed Apr 02, 2003 7:52 am Post subject: |
|
|
Acolyte
Joined: 27 Mar 2003 Posts: 64 Location: Arlington, Va
|
All of the setmqaut have been made for the q's, the qmanger objects, and the qmanager itself. Another applciation on the box connects to the same qmanager the exact same way and they dont get the exception "2035".
Refresh security has been run many times. A little more info, were running on Sun Solaris 8, the applications owner weblogic is part of the group mquser(which we created for mq). I ran the truss command against weblogic,
but I having a hard time understanding the truss contents.
truss -aelfd -u a.out -u "libmq*::" -u "libc::get*" -u "libc_r::get*" -o
(SOME OUTPUT FILE) -p (PID for the WebLogic Java process)
2831/293: 334.9635 -> libmqmcs:InitProcessVars(0xff0218, 0x0, 0xffffffff, 0xa4f5c190)
2831/293: 335.1722 -> libc:getuid(0x0, 0x0, 0x0, 0x0)
2831/293: 335.2045 getuid() = 4030 [4030]
2831/293: 335.2355 <- libc:getuid() = 4030
2831/293: 335.2585 -> libmqmcs:xcsGetpwuid(0xfbe, 0xa4dfec4c, 0xa4dfdf28, 0xd23)
2831/293: 335.2780 -> libc:getpwuid_r(0xfbe, 0xa4dfec4c, 0xa4dfdf28, 0xd23)
2831/293: 335.2943 open64("/etc/.name_service_door", O_RDONLY) = 304
2831/293: 335.3118 fcntl(304, F_SETFD, 0x00000001) = 0
2831/293: 335.3407 door_info(304, 0xFF342720) Err#9 EBADF
2831/293: 335.3704 close(304) = 0
2831/293: 335.4006 -> libc:getiop(0xff34027c, 0xff340414, 0xff340460, 0xecff68)
2831/293: 335.4223 <- libc:getiop() = 0
2831/293: 335.4411 -> libc:getiop(0xff34028c, 0xff340414, 0xff340414, 0x0)
2831/293: 335.4624 <- libc:getiop() = 0
2831/293: 335.4794 -> libc:getiop(0xff34029c, 0xff340414, 0xff340414, 0x0)
2831/293: 335.5107 <- libc:getiop() = 0
2831/293: 335.5456 -> libc:getiop(0xff3402ac, 0xff340414, 0xff340414, 0x0)
2831/293: 335.5792 <- libc:getiop() = 0xff3402ac
2831/293: 335.6144 open("/etc/passwd", O_RDONLY) = 304
2831/293: 335.6451 close(304) = 0
2831/293: 335.6762 <- libc:getpwuid_r() = 0
2831/293: 335.7094 <- libmqmcs:xcsGetpwuid() = 24
2831/293: 335.7271 <- libmqmcs:InitProcessVars() = 0
2831/293: 335.7459 <- libmqmcs:InitPrivateServices() = 0 |
|
Back to top |
|
 |
gward123 |
Posted: Fri Apr 04, 2003 10:36 am Post subject: |
|
|
 Novice
Joined: 27 Mar 2003 Posts: 11 Location: Roseland, NJ
|
The only thing that comes to mind for the troubled app is that the channel used when connecting via the client has MCAUSER hardcoded to give sufficient privileges or the client app is running under a different userid than the "server" bindings app (which would use the app servers id)? _________________ Gary J. Ward
Sr. Technical Consultant
ADP |
|
Back to top |
|
 |
meekings |
Posted: Fri Apr 04, 2003 10:59 am Post subject: |
|
|
 Voyager
Joined: 28 Jun 2001 Posts: 86 Location: UK, South West
|
As well as +get, +put and +browse, a JMS app needs +inq, which a regular app usually doesn't need (unless it opens for inquire). Check the authorizations for the user you're running as. Definitely as a client (unless you supply a username in your app or via MCAUSER), the app will be running with full privileges, so you won't encounter authorization problems. |
|
Back to top |
|
 |
csaunders |
Posted: Fri Apr 04, 2003 12:54 pm Post subject: |
|
|
Acolyte
Joined: 27 Mar 2003 Posts: 64 Location: Arlington, Va
|
both apps(troubled and working) are running as the same user. This is a clustered environment. Im starting to think its a SUN issue...... maybe this error is eroneous |
|
Back to top |
|
 |
meekings |
Posted: Fri Apr 04, 2003 1:15 pm Post subject: |
|
|
 Voyager
Joined: 28 Jun 2001 Posts: 86 Location: UK, South West
|
As a Java client, unless you're setting your user name in the app or in the MCAUSER channel parameter, the channel agent is running as mqm, regardless of the user you're starting the app up as, so it will have no authorization issues. In bindings mode, you're running under your own user name, and you may.
Check that your username has +connect and +inq on the QM, and +get, +put, +browse, +dsp and +inq on the queues (JMS has no concept of open for read, open for write, so opens for both). _________________ Brian Meekings
Information Design, Inc. |
|
Back to top |
|
 |
csaunders |
Posted: Mon Apr 07, 2003 10:56 am Post subject: |
|
|
Acolyte
Joined: 27 Mar 2003 Posts: 64 Location: Arlington, Va
|
How can I check to see if my username has +connect and +inq on the QM, and +get, +put, +browse, +dsp and +inq on the queues (JMS has no concept of open for read, open for write, so opens for both)? |
|
Back to top |
|
 |
vennela |
Posted: Mon Apr 07, 2003 11:46 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
the command is
dspmqaut
To set the authorities it is
setmqaut
do dspmqaut -? for usage
-------
Venny |
|
Back to top |
|
 |
syangloo |
Posted: Tue Apr 08, 2003 5:06 pm Post subject: |
|
|
Centurion
Joined: 01 Oct 2002 Posts: 120 Location: Kuala Lumpur
|
Other then checking the authority of you user id to the q and qmgr, please check you MCA field at the SYSTEM.DEF.SVRCONN channel.
I getting the same error at NT box with JMS, but it solve by taking out the user id at MCA fields in the SYSTEM.DEF.SVRCONN.
May be you have try it out.
Good Luck. |
|
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
|
|
|
|