|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
MQ App does not work outside Websphere bin folder |
« View previous topic :: View next topic » |
Author |
Message
|
lukechan |
Posted: Wed Feb 22, 2012 5:15 pm Post subject: MQ App does not work outside Websphere bin folder |
|
|
Newbie
Joined: 21 Feb 2012 Posts: 9
|
Dear all, this is my first post, I hope it will be kind on me
Currently I have a situation which I have developed an app to connect to MQ. It was working initially connecting to MQ but requirements has changed to connecting with SSL.
We have did some changes, but what happens now is that I realized that my app could only connect properly if it's in the Websphere\bin folder and not in my app folder. I have tried adding the Websphere\bin into the PATH environment but it did not work either.
Any ideas to why this is so? |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Feb 22, 2012 5:23 pm Post subject: Re: MQ App does not work outside Websphere bin folder |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
lukechan wrote: |
Dear all, this is my first post, I hope it will be kind on me
Currently I have a situation which I have developed an app to connect to MQ. It was working initially connecting to MQ but requirements has changed to connecting with SSL.
We have did some changes, but what happens now is that I realized that my app could only connect properly if it's in the Websphere\bin folder and not in my app folder. I have tried adding the Websphere\bin into the PATH environment but it did not work either.
Any ideas to why this is so? |
It did not work is not an error message I'm familiar with. It is also not a technical problem/symptom statement. As such, there is little/nothing we can do for you.
Exactly what symptom do you see that leads you to believe that it did not work? What error message(s)?
What problem-determination have you done? What were the results? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
mattfarney |
Posted: Wed Feb 22, 2012 5:30 pm Post subject: |
|
|
 Disciple
Joined: 17 Jan 2006 Posts: 167 Location: Ohio
|
My guess from the limited info in your post would be that you have a relative path somewhere that can only resolve from the MQ bin directory.
If it's for something like an INI file or perhaps the keystore for SSL, the connection failing would make sense.
-mf |
|
Back to top |
|
 |
mvic |
Posted: Wed Feb 22, 2012 5:46 pm Post subject: Re: MQ App does not work outside Websphere bin folder |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
lukechan wrote: |
Any ideas to why this is so? |
Please post some outputs, so we can see what errors you see. |
|
Back to top |
|
 |
lukechan |
Posted: Wed Feb 22, 2012 7:40 pm Post subject: |
|
|
Newbie
Joined: 21 Feb 2012 Posts: 9
|
So sorry for my noobness
Basically when I run a test tool containing the code to run on the app folder instead of the websphere\bin, it generates a much shorter trace file.
This is what I see from the end of the trace file when I run it from my app folder:
Code: |
000027F0 14:58:09.670657 3768.1 : !! - Thread stack
000027F1 14:58:09.670697 3768.1 : !! - -> InitProcessInitialisation
000027F2 14:58:09.670828 3768.1 : --{ InitProcessInitialisation
000027F3 14:58:09.670835 3768.1 : ---{ xcsReleaseThreadMutexSem
000027F4 14:58:09.670848 3768.1 : ---} xcsReleaseThreadMutexSem (rc=OK)
000027F5 14:58:09.670851 3768.1 : ---{ xcsGetEnvironmentString
000027F6 14:58:09.670906 3768.1 : xcsGetEnvironmentString[AMQ_REUSE_SHARED_THREAD] = NULL
000027F7 14:58:09.670912 3768.1 : ---}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
000027F8 14:58:09.670929 3768.1 : ---{ xcsGetEnvironmentInteger
000027F9 14:58:09.670932 3768.1 : ----{ xcsGetEnvironmentString
000027FA 14:58:09.670941 3768.1 : xcsGetEnvironmentString[AMQ_AFFINITY_MASK] = NULL
000027FB 14:58:09.670945 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
000027FC 14:58:09.670974 3768.1 : ---}! xcsGetEnvironmentInteger (rc=xecE_E_ENV_VAR_NOT_FOUND)
000027FD 14:58:09.670980 3768.1 : ---{ xcsGetEnvironmentString
000027FE 14:58:09.670989 3768.1 : xcsGetEnvironmentString[AMQ_FFSTINFO] = NULL
000027FF 14:58:09.670993 3768.1 : ---}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002800 14:58:09.670999 3768.1 : ---{ xcsIsEnvironment
00002801 14:58:09.671007 3768.1 : xcsIsEnvironment[AMQ_DEBUG_MTIME] = FALSE
00002802 14:58:09.671011 3768.1 : ---} xcsIsEnvironment (rc=OK)
00002803 14:58:09.671014 3768.1 : ---{ xcsGetEnvironmentInteger
00002804 14:58:09.671016 3768.1 : ----{ xcsGetEnvironmentString
00002805 14:58:09.671024 3768.1 : xcsGetEnvironmentString[AMQ_CBM_REUSE_FACTOR] = NULL
00002806 14:58:09.671028 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002807 14:58:09.671033 3768.1 : ---}! xcsGetEnvironmentInteger (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002808 14:58:09.671039 3768.1 : ---{ xcsGetEnvironmentInteger
00002809 14:58:09.671042 3768.1 : ----{ xcsGetEnvironmentString
0000280A 14:58:09.671050 3768.1 : xcsGetEnvironmentString[AMQ_CBM_MAX_CACHEABLE_SIZE] = NULL
0000280B 14:58:09.671053 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
0000280C 14:58:09.671059 3768.1 : ---}! xcsGetEnvironmentInteger (rc=xecE_E_ENV_VAR_NOT_FOUND)
0000280D 14:58:09.671065 3768.1 : ---{ xcsGetEnvironmentInteger
0000280E 14:58:09.671068 3768.1 : ----{ xcsGetEnvironmentString
0000280F 14:58:09.671075 3768.1 : xcsGetEnvironmentString[AMQ_CBM_LEN] = NULL
00002810 14:58:09.671079 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002811 14:58:09.671085 3768.1 : ---}! xcsGetEnvironmentInteger (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002812 14:58:09.671090 3768.1 : --} InitProcessInitialisation (rc=OK)
00002813 14:58:09.671194 3768.1 : --{ xcsInitialize
00002814 14:58:09.671208 3768.1 : ---{ xcsRequestThreadMutexSem
00002815 14:58:09.671219 3768.1 : ---} xcsRequestThreadMutexSem (rc=OK)
00002816 14:58:09.671233 3768.1 : ---{ xcsGetNTUserName
00002817 14:58:09.671438 3768.1 : UserName:mqappuser
00002818 14:58:09.671444 3768.1 : ---} xcsGetNTUserName (rc=OK)
00002819 14:58:09.671461 3768.1 : ---{ xcsGetNTOwnerSid
0000281A 14:58:09.671501 3768.1 : ---} xcsGetNTOwnerSid (rc=OK)
0000281B 14:58:09.671507 3768.1 : UserId: mqappuser
0000281C 14:58:09.671518 3768.1 : Sid: S-1-5-21-2201567343-3062099321-1652509054-1008
0000281D 14:58:09.671522 3768.1 : ---{ xcsReleaseThreadMutexSem
0000281E 14:58:09.671526 3768.1 : ---} xcsReleaseThreadMutexSem (rc=OK)
0000281F 14:58:09.671531 3768.1 : ---{ xihCSThreadClear
00002820 14:58:09.671546 3768.1 : ----{ xcsEmptyCBM
00002821 14:58:09.671550 3768.1 : ----} xcsEmptyCBM (rc=OK)
00002822 14:58:09.671554 3768.1 : ---} xihCSThreadClear (rc=OK)
00002823 14:58:09.671558 3768.1 : ---{ xcsUpdateThreadUserDetails
00002824 14:58:09.671561 3768.1 : ----{ xcsGetNTOwnerSid
00002825 14:58:09.671593 3768.1 : ----} xcsGetNTOwnerSid (rc=OK)
00002826 14:58:09.671600 3768.1 : Thread User Details
00002827 14:58:09.671605 3768.1 : UserName: mqappuser
00002828 14:58:09.671612 3768.1 : Sid: S-1-5-21-2201567343-3062099321-1652509054-1008
00002829 14:58:09.671615 3768.1 : ---} xcsUpdateThreadUserDetails (rc=OK)
0000282A 14:58:09.671619 3768.1 : ---{ xcsRequestThreadMutexSem
0000282B 14:58:09.671622 3768.1 : ---} xcsRequestThreadMutexSem (rc=OK)
0000282C 14:58:09.671626 3768.1 : ---{ xihCheckThreadList
0000282D 14:58:09.671629 3768.1 : ---} xihCheckThreadList (rc=OK)
0000282E 14:58:09.671645 3768.1 : ---{ xcsInitGlobalSecurityData
0000282F 14:58:09.671650 3768.1 : ---} xcsInitGlobalSecurityData (rc=OK)
00002830 14:58:09.671654 3768.1 : ---{ InitPrivateServices
00002831 14:58:09.671658 3768.1 : attributes 17415
00002832 14:58:09.671662 3768.1 : ----{ xcsGetEnvironmentString
00002833 14:58:09.671672 3768.1 : xcsGetEnvironmentString[AMQEXCEPTION] = NULL
00002834 14:58:09.671676 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002835 14:58:09.671682 3768.1 : ----{ xcsGetEnvironmentString
00002836 14:58:09.671690 3768.1 : xcsGetEnvironmentString[MQS_ACTION_ON_EXCEPTION] = NULL
00002837 14:58:09.671694 3768.1 : ----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002838 14:58:09.671704 3768.1 : pid MQ(4) system(3768)
00002839 14:58:09.671708 3768.1 : ---} InitPrivateServices (rc=OK)
0000283A 14:58:09.671711 3768.1 : ---{ xcsDerestrictProcessHandle
0000283B 14:58:09.671739 3768.1 : Successfully called Open Process
0000283C 14:58:09.671772 3768.1 : ---} xcsDerestrictProcessHandle (rc=OK)
0000283D 14:58:09.671777 3768.1 : ---{ xcsCreateNTSecurityAtts
0000283E 14:58:09.671803 3768.1 : ---} xcsCreateNTSecurityAtts (rc=OK)
0000283F 14:58:09.672074 3768.1 : ---{ xcsGetWorkPath
00002840 14:58:09.672113 3768.1 : ---} xcsGetWorkPath (rc=OK)
00002841 14:58:09.672119 3768.1 : ---{ xxxInitialize
00002842 14:58:09.672240 3768.1 : ----{ xgmDetermineMsgCatLanguage
00002843 14:58:09.672246 3768.1 : -----{ xcsGetEnvironmentString
00002844 14:58:09.672255 3768.1 : xcsGetEnvironmentString[MQS_FORCE_NTLANGID] = NULL
00002845 14:58:09.672259 3768.1 : -----}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002846 14:58:09.672307 3768.1 : -----{ xgmValidLanguage
00002847 14:58:09.672313 3768.1 : Provided language of 1033
00002848 14:58:09.672319 3768.1 : Using Language 1033 and CCSID 1252
00002849 14:58:09.672322 3768.1 : -----} xgmValidLanguage (rc=OK)
0000284A 14:58:09.672326 3768.1 : Using Language 1033 and CCSID 1252
0000284B 14:58:09.672330 3768.1 : ----} xgmDetermineMsgCatLanguage (rc=OK)
0000284C 14:58:09.672333 3768.1 : ----{ xcsIsEnvironment
0000284D 14:58:09.672350 3768.1 : xcsIsEnvironment[MQ_KEEP_LOCALE] = FALSE
0000284E 14:58:09.672355 3768.1 : ----} xcsIsEnvironment (rc=OK)
0000284F 14:58:09.672509 3768.1 : setlocale(LC_ALL, "")
00002850 14:58:09.672515 3768.1 : ----{ xcsGetConsoleOutputCP
00002851 14:58:09.672586 3768.1 : GetConsoleOutputCP=0
00002852 14:58:09.672592 3768.1 : ----}! xcsGetConsoleOutputCP (rc=Unknown(1B5))
00002853 14:58:09.672610 3768.1 : locale = English_United States.1252
00002854 14:58:09.673236 3768.1 : setlocale(LC_ALL, "English_United States.437")
00002855 14:58:09.673243 3768.1 : ----{ xcsGetMemFn
00002856 14:58:09.673258 3768.1 : component:23 function:207 length:32 options:0 cbmindex:-1 *pointer:003FB130
00002857 14:58:09.673263 3768.1 : ----} xcsGetMemFn (rc=OK)
00002858 14:58:09.673266 3768.1 : ----{ xcsCreateThreadMutexSem
00002859 14:58:09.673328 3768.1 : ----} xcsCreateThreadMutexSem (rc=OK)
0000285A 14:58:09.673338 3768.1 : ----{ xcsGetWorkPath
0000285B 14:58:09.673367 3768.1 : ----} xcsGetWorkPath (rc=OK)
0000285C 14:58:09.674533 3768.1 : ----{ xcsGetMemFn
0000285D 14:58:09.674585 3768.1 : component:23 function:207 length:12312 options:0 cbmindex:-1 *pointer:04280058
0000285E 14:58:09.674591 3768.1 : ----} xcsGetMemFn (rc=OK)
0000285F 14:58:09.674613 3768.1 : ----{ xcsGetMemFn
00002860 14:58:09.674620 3768.1 : component:23 function:207 length:8 options:0 cbmindex:-1 *pointer:003FB2B0
00002861 14:58:09.674624 3768.1 : ----} xcsGetMemFn (rc=OK)
00002862 14:58:09.676917 3768.1 : Information: No default set for EBCDIC data conversion in ccsid.tbl.
00002863 14:58:09.676925 3768.1 : Information: No default set for ASCII data conversion in ccsid.tbl.
00002864 14:58:09.676932 3768.1 : Common services CCSID selected is 437, Message Insert CCSID is 1252.
00002865 14:58:09.676936 3768.1 : ---} xxxInitialize (rc=OK)
00002866 14:58:09.676939 3768.1 : ---{ xcsGetEnvironmentString
00002867 14:58:09.676950 3768.1 : xcsGetEnvironmentString[AMQ_SERVICE_MODULE] = NULL
00002868 14:58:09.676953 3768.1 : ---}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002869 14:58:09.676962 3768.1 : ---{ xcsReleaseThreadMutexSem
0000286A 14:58:09.676966 3768.1 : ---} xcsReleaseThreadMutexSem (rc=OK)
0000286B 14:58:09.676968 3768.1 : --} xcsInitialize (rc=OK)
0000286C 14:58:09.677214 3768.1 : --{ xcsRegComp
0000286D 14:58:09.677222 3768.1 : comp:44 Count:0
0000286E 14:58:09.677227 3768.1 : --} xcsRegComp (rc=OK)
0000286F 14:58:09.679895 3768.1 : OS Version: Microsoft Windows NT 5.2.3790 Service Pack 2
00002870 14:58:09.679947 3768.1 : CLR Version: 2.0.50727.3053
00002871 14:58:09.680099 3768.1 : MachineName: TESTSERVER
00002872 14:58:09.680139 3768.1 : Command Line: "E:\Program Files\Myapp\Binary\mqapp.exe"
00002873 14:58:09.680534 3768.1 : ApartmentState: STA
00002874 14:58:09.680575 3768.1 : IsThreadPoolThread: False
00002875 14:58:09.680780 3768.1 : UserName: mqappuser
00002876 14:58:09.681139 3768.1 : UserDomainName: TESTSERVER
00002877 14:58:09.681654 3768.1 : OS Thread Id: 3744
00002878 14:58:09.681666 3768.1 : xcsInitialize Type: 0x00000407
00002879 14:58:09.681685 3768.1 : CommonServices: IBM.WMQ.MQCommonServices
0000287A 14:58:09.683410 3768.1 : Constructing IBM.WMQ.MQQueueManager#0202C666 lib/dotnet/pc/winnt/MQQueueManager.cs p000-L080414 1.56 08/04/10 14:41:46
0000287B 14:58:09.698517 3768.1 : --{ znetDUMMY
0000287C 14:58:09.698639 3768.1 : SCCSID: '@(#) lib/dotnet/pc/winnt/MQQueueManager.cs, dotnet, p000, p000-L080414 1.56 08/04/10 14:41:46'
0000287D 14:58:09.698734 3768.1 : ConnectOptions: QMgr = 'queue1', ConnName = '', Channel = ''
0000287E 14:58:09.733123 3768.1 : MQCNO.options: 0x00000040
0000287F 14:58:09.737653 3768.1 : ---{ xcsGetEnvironmentString
00002880 14:58:09.737809 3768.1 : xcsGetEnvironmentString[NMQ_MQ_LIB] = NULL
00002881 14:58:09.737816 3768.1 : ---}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
00002882 14:58:09.738037 3768.1 : BindingType from installed components
00002883 14:58:09.738050 3768.1 : BindingType = 'CLIENT' connectionType = 1
00002884 14:58:09.738255 3768.1 : Constructing IBM.WMQ.MQClientConnector#0218F99C lib/dotnet/pc/winnt/MQClientConnector.cs p000-L080414 1.27 08/04/10 15:04:24
00002885 14:58:09.740279 3768.1 : ---{ MQClientXaConnector.MQCLOSE(MQHCONN,ref MQHOBJ,MQLONG,out MQLONG,out MQLONG)
|
Forgive the length.
What I do find that is more from the above after I run from the websphere\bin are these:
The missing ini path does not seem to affect the connection...
Code: |
00000117 14:52:30.248162 5556.1 : Constructing IBM.WMQ.Nmqi.NmqiEnvironment#0202C666 lib/dotnet/pc/winnt/nmqi/NmqiEnvironment.cs p701-105-110415 1.2.1.2 10/09/22 11:28:13
00000118 14:52:30.252060 5556.1 : Constructing IBM.WMQ.MQClientCfg#0218F99C lib/dotnet/pc/winnt/nmqi/NmqiObject.cs p701-105-110415 1.1.1.1 09/08/17 00:27:26
00000119 14:52:30.252128 5556.1 : Constructing IBM.WMQ.MQClientCfg#0218F99C lib/dotnet/pc/winnt/nmqi/MQIniFile.cs p701-105-110415 1.1.1.2 10/09/17 09:38:29
0000011A 14:52:30.252148 5556.1 : Constructing IBM.WMQ.MQClientCfg#0218F99C lib/dotnet/pc/winnt/nmqi/MQClientCfg.cs p701-105-110415 1.1.1.1 09/08/17 00:21:02
0000011B 14:52:30.279336 5556.1 : --{ MQClientCfg.FindAndParse()
0000011C 14:52:30.282138 5556.1 : ---{ MQClientCfg.FindClientIni()
0000011D 14:52:30.282263 5556.1 : 2) mqclient.ini in PWD
0000011E 14:52:30.464374 5556.1 : Exception received
System.IO.FileNotFoundException
Message: Could not find file 'E:\Program Files\IBM\WebSphere MQ\bin\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()
|
I noticed these additional function calls that were absent from the unsuccessful run in my app folder:
Code: |
00000173 14:52:30.562976 5556.1 : Constructing IBM.WMQ.MQConnectionPool#01E6FA8E lib/dotnet/pc/winnt/nmqi/NmqiObject.cs p701-105-110415 1.1.1.1 09/08/17 00:27:26
00000174 14:52:30.563002 5556.1 : Constructing IBM.WMQ.MQConnectionPool#01E6FA8E lib/dotnet/pc/winnt/nmqi/MQConnectionPool.cs p701-105-110415 1.2.1.5 10/09/01 10:03:33
00000175 14:52:30.564575 5556.1 : Constructing IBM.WMQ.MQQueueManager#011ECF05 lib/dotnet/pc/winnt/baseclasses/MQManagedObject.cs p701-105-110415 1.2.1.3 10/09/06 16:17:08
|
Code: |
00000183 14:52:30.665316 5556.1 : Constructing IBM.WMQ.Nmqi.UnmanagedNmqiMQ#0215472D lib/dotnet/pc/winnt/nmqi/unmanaged/UnmanagedNmqiMQ.cs p701-105-110415 1.9.1.8 10/05/11 17:32:37
00000184 14:52:30.665417 5556.1 : ---} NmqiEnvironment.GetInstance(String,String) (rc=OK)
00000185 14:52:30.665429 5556.1 : --} NmqiEnvironment.GetMQI(int) (rc=OK)
00000186 14:52:30.668722 5556.1 : Constructing IBM.WMQ.MQConnectOptions#02BF8098 lib/dotnet/pc/winnt/nmqi/MQConnectOptions.cs p701-105-110415 1.1.1.2 10/09/14 13:33:11
00000187 14:52:30.669023 5556.1 : Constructing IBM.WMQ.MQChannelDefinition#00BB8560 lib/dotnet/pc/winnt/nmqi/MQChannelDefinition.cs p701-105-110415 1.3.1.2 09/09/03 09:20:01
00000188 14:52:30.673545 5556.1 : --{ MQChannelDefinition.setDefaultDefinition()
00000189 14:52:30.673557 5556.1 : --} MQChannelDefinition.setDefaultDefinition() (rc=OK)
0000018A 14:52:30.674057 5556.1 : Constructing IBM.WMQ.Nmqi.NmqiStructureFormatter#0297B065 lib/dotnet/pc/winnt/nmqi/NmqiStructureFormatter.cs p701-105-110415 1.2.1.1 09/08/17 00:27:54
|
This is the part which I felt is the successful connection (seems like a separate thread):
Code: |
000016BA 14:54:09.674443 5556.2 RSESS:000001 Channel Name:MQCHN01
000016BB 14:54:09.674447 5556.2 RSESS:000001 Sending Data:-
000016BB 14:54:09.674447 5556.2 RSESS:000001 0x0435CF00 54 53 48 20 00 00 00 2C 02 8B 30 00 00 00 00 00 : TSH ...,.‹0.....
000016BB 14:54:09.674447 5556.2 RSESS:000001 0x0435CF10 00 00 00 00 11 01 00 00 B5 01 00 00 00 00 00 2C : ...............,
000016BB 14:54:09.674447 5556.2 RSESS:000001 0x0435CF20 00 00 00 00 00 00 00 00 00 00 00 00 : ............
000016BC 14:54:09.674776 5556.2 RSESS:000001 -----------{ cciTcpSslWriteCallback
000016BD 14:54:09.674785 5556.2 RSESS:000001 cciTcpSslWriteCallback: input: nBytesToWrite=77
000016BE 14:54:09.674790 5556.2 RSESS:000001 ------------{ cciTcpSend
000016BF 14:54:09.674794 5556.2 RSESS:000001 -------------{ send
000016C0 14:54:09.674900 5556.2 RSESS:000001 -------------} send (rc=OK)
000016C1 14:54:09.674907 5556.2 RSESS:000001 Data: 0x0000004d
000016C2 14:54:09.674912 5556.2 RSESS:000001 Channel Name:MQCHN01
000016C3 14:54:09.674916 5556.2 RSESS:000001 Sending Data:-
000016C3 14:54:09.674916 5556.2 RSESS:000001 0x046856B8 17 03 00 00 48 BC 02 CC 02 9A 04 B8 AB A6 78 77 : ....H....š..«¦xw
000016C3 14:54:09.674916 5556.2 RSESS:000001 0x046856C8 65 22 31 C9 87 6E ED 28 A0 00 ED 4B A2 57 CC BB : e"1.‡nÃ( .ÃK¢W..
000016C3 14:54:09.674916 5556.2 RSESS:000001 0x046856D8 62 D0 F5 8E E7 DB B2 56 97 96 2F 8C 59 F2 20 0E : b..Žç..V—–/ŒY. .
000016C3 14:54:09.674916 5556.2 RSESS:000001 0x046856E8 38 B3 37 D2 46 0A A2 B0 72 AD 46 11 E6 23 07 10 : 8.7.F.¢.rÂF.æ#..
000016C3 14:54:09.674916 5556.2 RSESS:000001 0x046856F8 10 48 B1 47 72 0F 40 13 2E 21 6E 23 2C : .H.Gr.@..!n#,
000016C4 14:54:09.674966 5556.2 RSESS:000001 RetCode (OK)
000016C5 14:54:09.674970 5556.2 RSESS:000001 ------------} cciTcpSend (rc=OK)
000016C6 14:54:09.674974 5556.2 RSESS:000001 -----------}! cciTcpSslWriteCallback (rc=Unknown(4D))
000016C7 14:54:09.675022 5556.2 RSESS:000001 ----------} ccigsk_secure_soc_write (rc=OK)
000016C8 14:54:09.675028 5556.2 RSESS:000001 ---------} cciSslSecureSend (rc=OK)
000016C9 14:54:09.675032 5556.2 RSESS:000001 --------} ccxSend (rc=OK)
|
There is actually much more, but I wonder why these calls happen only when I run from the websphere\bin?
FYI, I have already set the environment variables (TAB, LIB etc.) that are required. The result is the same regardless I have the MQSERVER variable or not (not sure if it affects anyway).[/code] |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Feb 22, 2012 10:26 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
lukechan wrote: |
So sorry for my noobness
Basically when I run a test tool containing the code to run on the app folder instead of the websphere\bin, it generates a much shorter trace file. |
Let's start simple.
What test tool application program did you run? What is it's name?
How exactly did you run the program?
Run it again; then copy/paste the complete shell interaction here. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
JasonE |
Posted: Thu Feb 23, 2012 5:07 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
I'm not at all convinced that trace is complete...
For reference:
Quote: |
0000287D 14:58:09.698734 3768.1 : ConnectOptions: QMgr = 'queue1', ConnName = '', Channel = '' |
So if I trust this trace, you have constructed an MQQueueManager object, with name 'queue1' and not provided any connection or channel details
Quote: |
00002883 14:58:09.738050 3768.1 : BindingType = 'CLIENT' connectionType = 1 |
So it attempts a client (implicit, ie calculated) connection based on what you have installed. I think it then means it would try to load mqic32.dll from the path. This would then try to load a channel table using the environment variables (MQCHLLIB/TAB, MQSERVER), and then fail. I cant see quite how this would work from bin either!
Also
Quote: |
The missing ini path does not seem to affect the connection... |
Correct - expected behaviour, mqclient.ini is optional
Quote: |
I noticed these additional function calls that were absent from the unsuccessful run in my app folder: |
Yes, just is getting further.
Quote: |
This is the part which I felt is the successful connection (seems like a separate thread): |
Yes, thats just sending data so is normal once connected
One other oddity I noticed:
Failing: MQQueueManager.cs p000-L080414
Passing: MQConnectOptions.cs p701-105-110415
Its almost like you are picking up 2 versions of amqmdnet etc, when in bin using the product one (7.0.1.5 level) and outside of bin using a (something like 7.0.0.0 at a guess). Are you picking it up from the GAC or pointing to it with a config file, and if a config file are you using correct paths? |
|
Back to top |
|
 |
lukechan |
Posted: Thu Feb 23, 2012 5:49 pm Post subject: |
|
|
Newbie
Joined: 21 Feb 2012 Posts: 9
|
bruce2359 wrote: |
lukechan wrote: |
So sorry for my noobness
Basically when I run a test tool containing the code to run on the app folder instead of the websphere\bin, it generates a much shorter trace file. |
Let's start simple.
What test tool application program did you run? What is it's name?
How exactly did you run the program?
Run it again; then copy/paste the complete shell interaction here. |
It's actually the portion of our app coding that connects to MQ... |
|
Back to top |
|
 |
lukechan |
Posted: Thu Feb 23, 2012 6:06 pm Post subject: |
|
|
Newbie
Joined: 21 Feb 2012 Posts: 9
|
JasonE wrote: |
I'm not at all convinced that trace is complete... |
The first trace which is the unsuccessful connection, that is complete. The successful connection is a lengthly trace. Would I be allowed to put that here?
JasonE wrote: |
For reference:
Quote: |
0000287D 14:58:09.698734 3768.1 : ConnectOptions: QMgr = 'queue1', ConnName = '', Channel = '' |
So if I trust this trace, you have constructed an MQQueueManager object, with name 'queue1' and not provided any connection or channel details |
If the information is taken from the env vars, are the details required?
JasonE wrote: |
Quote: |
00002883 14:58:09.738050 3768.1 : BindingType = 'CLIENT' connectionType = 1 |
So it attempts a client (implicit, ie calculated) connection based on what you have installed. I think it then means it would try to load mqic32.dll from the path. This would then try to load a channel table using the environment variables (MQCHLLIB/TAB, MQSERVER), and then fail. I cant see quite how this would work from bin either!
Also
Quote: |
The missing ini path does not seem to affect the connection... |
Correct - expected behaviour, mqclient.ini is optional
Quote: |
I noticed these additional function calls that were absent from the unsuccessful run in my app folder: |
Yes, just is getting further.
Quote: |
This is the part which I felt is the successful connection (seems like a separate thread): |
Yes, thats just sending data so is normal once connected
One other oddity I noticed:
Failing: MQQueueManager.cs p000-L080414
Passing: MQConnectOptions.cs p701-105-110415
Its almost like you are picking up 2 versions of amqmdnet etc, when in bin using the product one (7.0.1.5 level) and outside of bin using a (something like 7.0.0.0 at a guess). Are you picking it up from the GAC or pointing to it with a config file, and if a config file are you using correct paths? |
We do have a copy of the dlls in our app folder. Prior to incorporating SSL, this setup works fine as the app does not work without it. Seems that is not the case now...
Should I not recall wrongly, removing those dlls from the app folder totally prevents my app from running. |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Feb 23, 2012 6:08 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
lukechan wrote: |
bruce2359 wrote: |
lukechan wrote: |
So sorry for my noobness
Basically when I run a test tool containing the code to run on the app folder instead of the websphere\bin, it generates a much shorter trace file. |
Let's start simple.
What test tool application program did you run? What is it's name?
How exactly did you run the program?
Run it again; then copy/paste the complete shell interaction here. |
It's actually the portion of our app coding that connects to MQ... |
Any chance that you can answer my questions?
Traces are not the normal output from applications.
What led you to look at a trace?
What symptom did you first see? Was it a ReasonCode? If so, what was it? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
lukechan |
Posted: Thu Feb 23, 2012 8:47 pm Post subject: |
|
|
Newbie
Joined: 21 Feb 2012 Posts: 9
|
Hi all,
I have managed to resolve the problem. It seems I need to copy all the amq* dlls from the websphere\bin to my app folder for it to work.
This sounds weird as the system should be able to locate the websphere\bin dlls, isn't it? Apart from adding the path into the PATH environment variable, is there anything else required to be done? |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Feb 23, 2012 9:04 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Have you read the client manual and specifically the need for an mqclient.ini file? Do you have such a file in your app directory? Remember it is not a good practice to copy the amq*.dll files as you 'd get a mixed environment after an upgrade... or fix pack has been applied...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Feb 24, 2012 1:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The only way to run a .NET application without installing a full MQ client is if you build the connection as a managed connection and then ensure that you take the one appropriate amqm*.dll along with your application.
This does then make your app tied very very tightly to a specific fixpack and level of MQ - because the only way to update that in your app is to update the amqm*.dll you have. |
|
Back to top |
|
 |
JasonE |
Posted: Fri Feb 24, 2012 1:57 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Please do not copy MQ dlls around - I have spent so long debugging problems caused by people who do this. If you need MQ .net code, reference it from the GAC (in fact, I dont quite understand why it doesnt work anyway - .net searches the GAC first I thought...?) or use a .config file...
So remove the amq* from your application directory, make sure MQ is installed on the box (client or server) and to double check things are registered ok, in a command prompt sitting in the MQ bin directory, run amqiregisterdotnet |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Feb 24, 2012 2:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
JasonE wrote: |
Please do not copy MQ dlls around - I have spent so long debugging problems caused by people who do this. If you need MQ .net code, reference it from the GAC (in fact, I dont quite understand why it doesnt work anyway - .net searches the GAC first I thought...?) or use a .config file... |
Again, no client install. "Zero config", right? |
|
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
|
|
|
|