| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| .NET - MQRC_CD_ERROR |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Fri Feb 26, 2010 4:00 am Post subject: .NET - MQRC_CD_ERROR |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Help needed please...I'm not a developer and I'm at the end of my knowledge base with this one.
BACKGROUND
The requirement (ours, so it fits within the client-side architecture being promoted at the site) is for the application to connect as an unmanaged client, and to use a CCDT/SSL key store as specified in the CHANNELS and SSL stanzas of an mqclient.ini file. The queue manager name passed will always be *.
APPLICATION
It's an exe that runs under IIS, and due to the SSL requirement the website will run under a domain user ID; I do not have access to their code (yet!). It is a 'vanilla' .NET app, i.e. not XMS-based. All it does (apparently) is put messages on a queue, and get messages from a queue.
DEVELOPMENT INFRASTRUCTURE
The application developers have full access to the development server and add/remove users from groups at will. Also, the installation of WMQ is non-domain mode (which is not the site standard for V7.0.1). I set the NMQ_MQ_LIB variable/customisation value to mqic.dll. The application works in this environment.
SYSTEM TEST ENVIRONMENT
The application developers do not control, or have the same access in this environment. WMQ is installed properly, i.e. in domain mode, and the appropriate variable/customisation value is set the same as in Development. The application does not work in this environment.
FAULT DIAGNOSIS
I have checked the Development set-up and frankly it is a mess. Apart from the obvious difference in WMQ installation modes, trying to align it with the other environment is a fruitless task as continuous changes are made.
I switched on tracing at WMQ-level in the Sys Test environment and can see that the 'default' mqclient.ini file is being found, and that the channeldefinitiondirectory, channeldefinitionfile and sslkeyrepository values are being parsed, but it bombs out with:
| Quote: |
| Exception received System.ArgumentException Message: exePath must be specified when not running inside a stand alone exe. StackTrace: at System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath) at System.Configuration.ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel userLevel) at IBM.WMQ.MQClientCfg.FindAndParse() |
I'm pretty much convinced that the issue is that the content of the CCDT is not being parsed, hence why the MQRC 2277, but I can't work out why the difference in each environment - I wanted to uninstall/reinstall WMQ in Dev to align it with the other environment, but time pressure has prevented it.
ADDITIONAL INFORMATION
The developers tell me that they do not use an application configuration file, and I couldn't find any references to the application in the web.config file.
At the moment this is causing the developers and I to go around in circles because I'm sure it's application-environmental, and of course they're convinced it's WMQ-environmental 
If anyone out there can shed some light on this I would be extremely grateful, thank you.
_________________
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 |
|
 |
| fjb_saper |
| Posted: Fri Feb 26, 2010 4:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
From your error message it looks like IIS and the MQ client used by IIS may not run under the same ID. When using a different ID make sure that the path has all the information needed to run MQ.
| Quote: |
| System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath) |
So either the user IIS uses to run MQ does not have all the priviledges needed or misses some directories in its path statement... or this applies to the IIS user...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 5:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
From your error message it looks like IIS and the MQ client used by IIS may not run under the same ID. When using a different ID make sure that the path has all the information needed to run MQ.
| Quote: |
| System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath) |
So either the user IIS uses to run MQ does not have all the priviledges needed or misses some directories in its path statement... or this applies to the IIS user...
Have fun |
Thank you for the answer fj but to check that we put the user that runs IIS in the Admins group and recycled IIS - no difference. I'm beginning to think it worked in Dev because of the 'local' install of WMQ, and running IIS under NETWORK SERVICE, and maybe in domain mode they have to point ConfigurationManager to a specific userLevel of none, or the user is considered to be 'roaming'? It's all greek to me
The trace file also trapped the application user, which was the same as that shown in Task Manager as running the exe.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Feb 26, 2010 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
FJ was also suggesting that you look at the PATH environment when the app runs inside IIS.
It's probably useful to troubleshoot this the same way you would troubleshoot a triggered application. I don't know if you can run the app "stand-alone" or not.
There may also be a way to get IIS to run it "interactively" in the foreground so you can see what the app does better.
Can you set up amqscnxc as an IIS run application as the same user and does it find the CCDT or does it throw the same 2277? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 6:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Jeff,
Thank you for the input. I don't know whether the whole app can be run stand-alone; during the initial development stage the developers did run the WMQ 'stub' as stand-alone, but then integrated it into the whole. The only issues then were warnings (MQRC_SELECTOR_ERROR) on connect, but otherwise all else was good.
As stated in the original post, the trace file is showing that the paths are being resolved (com.ibm.mq.cfg.channels.channeldefinitiondirectory=C:\Appl\IBM\<redacted>). We are currently trying the paths as a fully qualified share path to see if that makes a difference. As we put the user IIS runs under in the Admins group, I would have thought that would take pathing out of the equation, but we'll check anyway.
UPDATE: Just heard back that changing to a shared path also failed.
_________________
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 |
|
|
| mvic |
| Posted: Fri Feb 26, 2010 7:01 am Post subject: Re: .NET - MQRC_CD_ERROR |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| exerk wrote: |
| I'm pretty much convinced that the issue is that the content of the CCDT is not being parsed, hence why the MQRC 2277 |
Where is the 2277 being seen.. can you post the relevant bit of output with context? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 7:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Some elements redacted for obvious reasons...
Top of the application trace:
| Code: |
Process : c:\windows\system32\inetsrv\<redacted>.exe (32-bit)
Host : <redacted>
Operating System : Windows Server 2003, Build 3790: SP2
Product Long Name : WebSphere MQ for Windows
Version : 7.0.1.1 Level : p701-101-091221 |
Further in:
| Code: |
.
.
.
000008CA 10:52:23.778552 268.1 : Command Line: c:\windows\system32\inetsrv\<redacted>.exe -a \\.\pipe\iisipm8aa53e86-a6d5-486d-b3fa-ebe1b8cde729 -t 20 -ap "<redacted>"
000008CB 10:52:23.778832 268.1 : ApartmentState: MTA
000008CC 10:52:23.778869 268.1 : IsThreadPoolThread: True
000008CD 10:52:23.779154 268.1 : UserName: <redacted but what IIS runs under>
000008CE 10:52:23.780405 268.1 : UserDomainName: <redacted>
000008CF 10:52:23.782091 268.1 : OS Thread Id: 2056
000008D0 10:52:23.782143 268.1 : xcsInitialize Type: 0x00000407
000008D1 10:52:23.782200 268.1 : CommonServices: IBM.WMQ.MQCommonServices
000008D2 10:52:23.785165 268.1 : Constructing IBM.WMQ.Nmqi.NmqiEnvironment#0119E831 lib/dotnet/pc/winnt/nmqi/NmqiEnvironment.cs p701-101-091221 1.2.1.1 09/08/17 00:26:46
000008D3 10:52:23.793509 268.1 : Constructing IBM.WMQ.MQClientCfg#01E929C1 lib/dotnet/pc/winnt/nmqi/NmqiObject.cs p701-101-091221 1.1.1.1 09/08/17 00:27:26
000008D4 10:52:23.793570 268.1 : Constructing IBM.WMQ.MQClientCfg#01E929C1 lib/dotnet/pc/winnt/nmqi/MQIniFile.cs p701-101-091221 1.1.1.1 09/08/17 00:23:15
000008D5 10:52:23.793612 268.1 : Constructing IBM.WMQ.MQClientCfg#01E929C1 lib/dotnet/pc/winnt/nmqi/MQClientCfg.cs p701-101-091221 1.1.1.1 09/08/17 00:21:02
000008D6 10:52:23.795980 268.1 : --{ MQClientCfg.FindAndParse()
000008D7 10:52:23.814088 268.1 : ---{ MQClientCfg.FindClientIni()
000008D8 10:52:23.814363 268.1 : 2) mqclient.ini in PWD
000008D9 10:52:23.823522 268.1 : Exception received
System.IO.FileNotFoundException
Message: Could not find file 'c:\windows\system32\inetsrv\mqclient.ini'.
StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at IBM.WMQ.MQClientCfg.FindClientIni()
000008DA 10:52:23.825120 268.1 : ---} MQClientCfg.FindClientIni() (rc=OK)
.
.
. |
Other appropriate lines:
| Code: |
.
.
.
000008F8 10:52:23.837054 268.1 : Stanza:com.ibm.mq.cfg.channels
.
000008FE 10:52:23.838046 268.1 : -----{ MQIniFile.StoreAttributeValuePair(String,String)
000008FF 10:52:23.838078 268.1 : com.ibm.mq.cfg.channels.channeldefinitiondirectory=C:\Appl\IBM\<redacted>
00000900 10:52:23.838102 268.1 : -----} MQIniFile.StoreAttributeValuePair(String,String) (rc=OK)
.
.
.
00000906 10:52:23.838242 268.1 : com.ibm.mq.cfg.channels.channeldefinitionfile=<redacted>.TAB
00000907 10:52:23.838264 268.1 : -----} MQIniFile.StoreAttributeValuePair(String,String) (rc=OK)
00000908 10:52:23.838282 268.1 : ----} MQIniFile.ProcessCurrentLine() (rc=OK)
.
.
.
00000925 10:52:23.838935 268.1 : -----{ MQIniFile.StoreAttributeValuePair(String,String)
00000926 10:52:23.838959 268.1 : com.ibm.mq.cfg.ssl.sslkeyrepository=C:\Appl\IBM\<redacted>\<redacted>
00000927 10:52:23.838981 268.1 : -----} MQIniFile.StoreAttributeValuePair(String,String) (rc=OK)
.
.
.
0000093E 10:52:23.852703 268.1 : Exception received
System.ArgumentException
Message: exePath must be specified when not running inside a stand alone exe.
StackTrace:
at System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath)
at System.Configuration.ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel userLevel)
at IBM.WMQ.MQClientCfg.FindAndParse()
0000093F 10:52:23.852758 268.1 : --} MQClientCfg.FindAndParse() (rc=OK)
00000940 10:52:23.853573 268.1 : Constructing IBM.WMQ.MQConnectionPool#013277CA lib/dotnet/pc/winnt/nmqi/NmqiObject.cs p701-101-091221 1.1.1.1 09/08/17 00:27:26
00000941 10:52:23.853625 268.1 : Constructing IBM.WMQ.MQConnectionPool#013277CA lib/dotnet/pc/winnt/nmqi/MQConnectionPool.cs p701-101-091221 1.2.1.1 09/08/17 00:21:28
00000942 10:52:23.855063 268.1 : Constructing IBM.WMQ.MQQueueManager#02C6361F lib/dotnet/pc/winnt/baseclasses/MQManagedObject.cs p701-101-091221 1.2.1.1 09/08/17 01:15:45
00000943 10:52:23.855117 268.1 : Constructing IBM.WMQ.MQQueueManager#02C6361F lib/dotnet/pc/winnt/baseclasses/MQQueueManager.cs p701-101-091221 1.3.1.4 09/10/30 12:56:32
00000944 10:52:23.888441 268.1 : SCCSID: '@(#) lib/dotnet/pc/winnt/baseclasses/MQQueueManager.cs, dotnet, p701, p701-101-091221 1.3.1.4 09/10/30 12:56:32'
00000945 10:52:23.888782 268.1 : ConnectOptions: QMgr = '*', ConnName = '', Channel = ''
00000946 10:52:23.890942 268.1 : MQCNO.options: 0x00000040
00000947 10:52:23.898622 268.1 : --{ xcsGetEnvironmentString
00000948 10:52:23.898805 268.1 : xcsGetEnvironmentString[NMQ_MQ_LIB] = 'mqic.dll'
00000949 10:52:23.898838 268.1 : --} xcsGetEnvironmentString (rc=OK)
0000094A 10:52:23.899084 268.1 : BindingType from NMQ_MQ_LIB
0000094B 10:52:23.899118 268.1 : BindingType = 'CLIENT' connectionType = 2
0000094C 10:52:23.902043 268.1 : --{ NmqiEnvironment.GetMQI(int)
0000094D 10:52:23.902095 268.1 : Component ID Supplied -> 1
0000094E 10:52:23.902122 268.1 : Component Name -> IBM.WMQ.Nmqi.UnmanagedNmqiMQ
.
.
. |
The last lines of the trace show:
| Code: |
.
.
.
0000126A 10:52:24.631415 268.2 : OS Version: Microsoft Windows NT 5.2.3790 Service Pack 2
0000126B 10:52:24.631470 268.2 : CLR Version: 2.0.50727.42
0000126C 10:52:24.631820 268.2 : MachineName: <redacted>
0000126D 10:52:24.631865 268.2 : Command Line: c:\windows\system32\inetsrv\<redacted>.exe -a \\.\pipe\iisipm8aa53e86-a6d5-486d-b3fa-ebe1b8cde729 -t 20 -ap "<redacted>"
0000126E 10:52:24.632092 268.2 : ApartmentState: MTA
0000126F 10:52:24.632142 268.2 : IsThreadPoolThread: False
00001270 10:52:24.632432 268.2 : UserName: <redacted>
00001271 10:52:24.632591 268.2 : UserDomainName: <redacted>
00001272 10:52:24.632621 268.2 : OS Thread Id: 2808
00001273 10:52:24.632649 268.2 : xcsInitialize Type: 0x00000407
00001274 10:52:24.632717 268.2 : CommonServices: IBM.WMQ.MQCommonServices
00001275 10:52:24.632742 268.2 : --{ MQQueueManager.Dispose(Boolean)
00001276 10:52:24.633185 268.2 : Constructing IBM.WMQ.Nmqi.HconnAdapter#00784086 lib/dotnet/pc/winnt/nmqi/handles/HconnAdapter.cs p701-101-091221 1.1.1.1 09/08/17 00:15:02
00001277 10:52:24.633212 268.2 : --}! MQQueueManager.Dispose(Boolean) (rc=MQRC_CD_ERROR)
.
.
. |
Everything I see suggests that the CCDT is being found, but that its contents are not being extracted and passed in, and I've only just noticed this line myself (how many times have I looked at this and missed it?):
| Code: |
| 0000093F 10:52:23.852758 268.1 : --} MQClientCfg.FindAndParse() (rc=OK) |
oops 
ADDITIONAL INFORMATION: The whole configuration, i.e. checking the mqclient.ini file was accurate, was tested using the amqsputc/amqsgetc samples and was successful.
mvic,
If there's anything specific you want me to hunt through the application trace file for, please ask.
_________________
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 |
|
|
| mvic |
| Posted: Fri Feb 26, 2010 8:18 am Post subject: Re: .NET - MQRC_CD_ERROR |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
It's possible the rc= in this line
| Code: |
| 00001277 10:52:24.633212 268.2 : --}! MQQueueManager.Dispose(Boolean) (rc=MQRC_CD_ERROR) |
is misleading if, as I suspect, that method actually returns void. However I admit to having no .NET experience, so I could be wrong.. It's possible this is a stored return value from earlier in the execution of this thread - do 2277, 8e5 or MQRC_CD_ERROR appear anywhere else in the trace?
Lastly the exception you focussed on at first looks to be ignored, as an ini file had been found using other means.
I recommend you raise a PMR soon if you are being held up by this issue. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 8:27 am Post subject: Re: .NET - MQRC_CD_ERROR |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mvic wrote: |
It's possible the rc= in this line
| Code: |
| 00001277 10:52:24.633212 268.2 : --}! MQQueueManager.Dispose(Boolean) (rc=MQRC_CD_ERROR) |
is misleading if, as I suspect, that method actually returns void. However I admit to having no .NET experience, so I could be wrong.. It's possible this is a stored return value from earlier in the execution of this thread - do 2277, 8e5 or MQRC_CD_ERROR appear anywhere else in the trace?
Lastly the exception you focussed on at first looks to be ignored, as an ini file had been found using other means.
I recommend you raise a PMR soon if you are being held up by this issue. |
I'm no developer, and may be completely wrong, so will be more than happy to be corrected on this, but observed behaviour suggests to me that a CONNX structure should be built using the information from the CCDT, hence the 2277 as some of the fields are empty. There are quite a few areas within the trace that the 2277 shows up, and if I haven't solved this by Monday, it'll definitely be PMR time.
It's so frustrating that it works in one environment (albeit it could be the difference in WMQ installation/configuration) and not in another. Worse, I just know it's going to be something simple that I'm overlooking 
_________________
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 |
|
|
| mvic |
| Posted: Fri Feb 26, 2010 8:43 am Post subject: Re: .NET - MQRC_CD_ERROR |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| exerk wrote: |
| There are quite a few areas within the trace that the 2277 shows up |
Is the 2277 error actually thrown to the app, or is it another error that the app sees?
If, from an intact CCDT, MQ had failed to build a good MQCD, this would strike me as a defect inside MQ. However I don't know if that is what has happened.. I still have reservations as I don't see a reason why the 2277 error appears in the first place.
Hope you get it fixed.. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 8:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
From what I can see, the error is being thrown to the app. When testing with the stand-alone application, one thing I did notice was that '...BindingType = 'CLIENT' connectionType = 1...' appeared in the trace (I traced it out of curiosity to see what was being passed). Also, the channel name etc. was populated, and the only place they could have come from was the CCDT.
_________________
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 |
|
|
| mvic |
| Posted: Fri Feb 26, 2010 9:31 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| exerk wrote: |
| From what I can see, the error is being thrown to the app. |
What are your app people complaining of, precisely? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 10:58 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If I set the NMQ_MQ_LIB variable, the 2277 occurs; if I remove the variable the error changes to 2058. As an experiment, I got them to pass the information contained in the CCDT as values in a hashtable, and all worked fine, so I'm pretty confident that their code is functionally good.
I've taken one of the .NET sample programmes (vmqsput.vb) and have managed to reproduce the problem, but going forward from there is where my limitation lies - I don't know enough to begin to look for where the problem lies.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Feb 26, 2010 11:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| does amqscnxc work with the ccdt? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 26, 2010 11:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| does amqscnxc work with the ccdt? |
It will be Monday now before I can test that Jeff, but will do so at the earliest opportunity.
_________________
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 |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
