| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| .Net - AccessQueue issue with multi-threaded client program |
« View previous topic :: View next topic » |
| Author |
Message
|
| johnb |
 Posted: Wed Mar 22, 2006 12:35 am Post subject: .Net - AccessQueue issue with multi-threaded client program |
 |
|
Newbie
Joined: 21 Mar 2006
Posts: 3
Location: London
|
Hi all,
I have a class which opens a queue thus:
mqQMgr = new MQQueueManager(
outputQueueManagerName,
channelName,
connectionName );
...
mqQueue = mqQMgr.AccessQueue(
outputQueueName,
MQC.MQOO_OUTPUT +
MQC.MQOO_FAIL_IF_QUIESCING +
MQC.MQOO_SET_IDENTITY_CONTEXT);
both mqQMgr and mqQueue are local to the method. Connection is via a svrconn channel to Solaris server v5.3 CSD11. Client is 5.3 CSD9. Client program is written in C#. The user as whom the client runs has the folowing perms on the queue:
get, browse, put, inq, set, passid, passall.
If I call the method from a single thread, everything works. If I call the method from multiple threads, the AccessQueue fails with a 2035. When I try the test queue manager, where the user is part of the mqm group, all is well from the single-threaded and multi-threaded clients.
What extra permissions do I need on the queue to allow my MT client to access it? Why the difference?
Cheers, John |
|
| Back to top |
|
 |
| questro |
| Posted: Wed Mar 22, 2006 1:04 am Post subject: Re: .Net - AccessQueue issue with multi-threaded client prog |
|
|
Newbie
Joined: 07 Mar 2006
Posts: 9
Location: Magic Land
|
| johnb wrote: |
mqQueue = mqQMgr.AccessQueue(
outputQueueName,
MQC.MQOO_OUTPUT +
MQC.MQOO_FAIL_IF_QUIESCING +
MQC.MQOO_SET_IDENTITY_CONTEXT);
|
On the face of it, the fact that you are specifying MQOO_SET_IDENTITY_CONTEXT implies that the user under which the application is running should have the setid authority (which from your post, is not the case) - but this doesn't explain your findings with the multi-threaded vs single-threaded invocation. In fact all requests should fail as observed, with 2035 (MQRC_NOT_AUTHORIZED).
| johnb wrote: |
If I call the method from a single thread, everything works. If I call the method from multiple threads, the AccessQueue fails with a 2035. When I try the test queue manager, where the user is part of the mqm group, all is well from the single-threaded and multi-threaded clients.
|
This too does suggest that it's the setid authority problem (apart from the single vs multi threaded thing!). Members of the mqm group have full authority to all objects in the queue manager, so the lack of setid is irrelevant - you could try running under another userid but with the test queue manager to prove this.
| johnb wrote: |
Why the difference?
|
Well... there shouldn't be a difference, perhaps in the single threaded case it was actually running under a different userid but you weren't aware of that? |
|
| Back to top |
|
|
| johnb |
| Posted: Thu Mar 23, 2006 7:17 am Post subject: Thanks |
|
|
Newbie
Joined: 21 Mar 2006
Posts: 3
Location: London
|
Thanks for the reply. I have verified on my test QM that taking away setid results in the multi-threaded client failing and the single-threaded client continuing as if nothing had happened.
I now have a solution to the immediate problem. Or will have once the admins have sorted out the production system.
However, the different behaviour of the clients is still interesting. As far as the user names go, both clients are started as a windows service with the same username, which IIRR is passed as a string to the QM. Unless windows has something wacky with its threads (like threads running in the same process have different userids) then I have to think it's a bug in the .Net MQ client somewhere.
If I get to the bottom of it, I shall post the resolution.
Thanks again,
--
John |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 23, 2006 7:56 am Post subject: Re: Thanks |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Simply noting that the client is multi-threaded is not enough information to enable analysis of why one fails and the other succeeds. You'd have to look more into the actual code that is running in the two cases, and especially the options being passed into MQOPEN, MQPUT etc.
As with all other MQ authorization failures, you can analyse the problem from the server side using (a) auth events or (b) MQ trace. This should reveal what username MQ is using for its authority checks, and the reason for the authorization failure.
EDIT: fix typo and clarify |
|
| Back to top |
|
|
| johnb |
| Posted: Thu Mar 23, 2006 8:57 am Post subject: |
|
|
Newbie
Joined: 21 Mar 2006
Posts: 3
Location: London
|
Well, the actual code is exactly the same in both cases, only in one case it runs from the service's only thread, and in the other case it runs from 5 or 6 threads created from the original thread. Each thread creates a QM object and calls QM.AccessQueue. The first time any thread in the MT service does the AccessQueue, I get the 2035.
I shall look into auth events.
Cheers, John |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 23, 2006 1:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
But is the service thread impersonating a principal which does not get passed to the spawned off threads ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 23, 2006 1:49 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
| But is the service thread impersonating a principal which does not get passed to the spawned off threads ? |
Trace first, ask questions later 
johnb, you will come back and tell us what you find, won't you? ...please. |
|
| 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
|
|
|
|
