|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Does amqmdnet.dll ever swallow errors? |
« View previous topic :: View next topic » |
Author |
Message
|
DeanR |
Posted: Fri Mar 17, 2006 4:49 am Post subject: Does amqmdnet.dll ever swallow errors? |
|
|
Newbie
Joined: 17 Mar 2006 Posts: 3
|
Hi all,
We're using a .NET client app to post messages to an MQSeries (Version: 5.3) queue using the amqmdnet.dll library.
We're occassionally getting the following errors in the client event log when we attempt a Put:
Event Log Entry 1
"An internal WebSphere MQ error has occurred.
An error has been detected, and the MQ error recording routine has been called.
Details of the error have been stored at C:\Program Files\IBM\WebSphere MQ\errors\AMQ02328.19.FDC. A synopsis is given in the data section below. Use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved."
Wed March 08 12:05:40 GMT Standard Time 2006 ,
Host Name :- TEST0020 (Windows XP Build 2600: Service Pack 1),
PIDS:- 5724B4100 ,
LVLS :- 530.9 CSD09,
Product Long Name :- WebSphere MQ for Windows,
Vendor :- IBM,
Probe Id :- XC381010,
Application Name :- MQM ,
Component :- xcsDisplayMessageForSubpool,
Build Date :- Dec 13 2004,
CMVC level :- p530-09-L041213,
Build Type :- IKAP - (Production),
UserID :- TESTUSER20,
Process Name :- SystemTray.exe,
Process :28,
Thread :- 8,
Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC,
Minor Errorcode :- OK,
Probe Type :- MSGAMQ6119 ,
Probe Severity :- 2,
Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred (WinNT error 5 from DosOpen.),
FDCSequenceNumber :- 1,
Comment1 :- WinNT error 5 from DosOpen.
Comment2 :- Access is denied.
Component Dumps (Thread 00000008),-------------------------------------,
Event Log Entry 2
"Allocate failed to host '31.130.192.175'.
The attempt to allocate a conversation using TCP/IP to host <<ip address removed>> was not successful.
The error may be due to an incorrect entry in the TCP/IP parameters contained in the channel definition to host <<ip address removed>>. Correct the error and try again. If the error persists, record the error values and contact your systems administrator. The return code from the TCP/IP (connect) call was 10065 (X'2751'). It may be possible that the listening program at host <<ip address removed>> is not running. If this is the case, perform the relevant operations to start the listening program for protocol TCP/IP and try again."
Now I (think) can explain these errors with sporadic network connectivity because subsequent message submissions appear to work. But the real problem is that we're losing the message that we're trying to post when these errors do occur. Unfortunately the calling .NET code never get's an exception, and so believes the .Put() has succeeded and removes the message from the Source queue.
Is it possible that the amqmdnet.dll API is "swallowing" errors and thus never reporting it back to the client?
Further compounding the debugging of this problem is the location where the AMQ02328.19.FDC file is written to is empty?! It seems to be cleared every time the machine re-boots?
I'd appreciate any help you can offer, becuase the Business aren't happy with "dissapearing messages"
Thanks,
Dean |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Mar 17, 2006 4:56 am Post subject: Re: Does amqmdnet.dll ever swallow errors? |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
DeanR wrote: |
Now I (think) can explain these errors with sporadic network connectivity because subsequent message submissions appear to work. But the real problem is that we're losing the message that we're trying to post when these errors do occur. Unfortunately the calling .NET code never get's an exception, and so believes the .Put() has succeeded and removes the message from the Source queue.
Is it possible that the amqmdnet.dll API is "swallowing" errors and thus never reporting it back to the client?
Further compounding the debugging of this problem is the location where the AMQ02328.19.FDC file is written to is empty?! It seems to be cleared every time the machine re-boots?
I'd appreciate any help you can offer, becuase the Business aren't happy with "dissapearing messages"
Thanks,
Dean |
Are you using syncpoint? If you are concerned about loosing messages due to network you should be doing 4 things:
a) install a qmgr on the same machine as your consuming/producing app.
b) use syncpoint to ensure transaction integrity
c) multiphase commit
d) have your messages be persistent
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
DeanR |
Posted: Fri Mar 17, 2006 7:33 am Post subject: |
|
|
Newbie
Joined: 17 Mar 2006 Posts: 3
|
Hi fjb_saper,
Thanks for your prompt response.
We are using the MQPMO_SYNCPOINT message option, and are doing an explicit 2-phase commit in code, but we can't install a QueueManager onto the client for various reasons.
So regarding my original question, is it possible that the errors seen in the Event Log would have resulted in MQCC_WARNING instead of a MQCC_FAILED result? Is it possible that a connection error could fall under the threshold and never get propogated?
Thanks,
Dean |
|
Back to top |
|
 |
wschutz |
Posted: Fri Mar 17, 2006 7:54 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
First, can you upgrade to CSD11 or 12? I see: LVLS :- 530.9 CSD09, which has some known problems ....
second, it doesn't seem like directory permission are setup correctly:
Comment1 :- WinNT error 5 from DosOpen.
Comment2 :- Access is denied.
that should be fixed...
third, can you be sure that your program is actually checking for errors after the put call?
fourth, you are saying that you're using the client bindings AND two phase (XA) commit? _________________ -wayne |
|
Back to top |
|
 |
DeanR |
Posted: Fri Mar 17, 2006 8:27 am Post subject: |
|
|
Newbie
Joined: 17 Mar 2006 Posts: 3
|
Hi wschutz
Thanks for the reply.
1. I'll look into upgrading the library to CSD11 or 12. Can you provide a link where the known problems with CSD9 are listed?
2. Ok that makes a bit more sense now. I've checked the laptop and you're right - the client app doesn't have write permissions to the MQ log directory, which is why the FDC file is missing. So "Event Log Entry 1" in my original post is a red herring.
3. That still leaves possible exceptions getting swallowed. The Put(...) and Commit() calls are wrapped in a try{..}catch{MQException} block. If a MQException is caught, we then check the .ReasonCode property to make sure the Exception isn't because of a transient network (i.e. MQC.MQRC_NO_MSG_AVAILABLE, MQC.MQRC_CONNECTION_BROKEN etc)
4. We're using MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING when accessing the queue and MQC.MQPMO_SYNCPOINT|MQC.MQPMO_FAIL_IF_QUIESCING on the QueuePutMessageOptions parameter. Then after the Put(..) has completed we call Commit().
Does this clarify things?
Thanks,
Dean |
|
Back to top |
|
 |
wschutz |
Posted: Fri Mar 17, 2006 8:52 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
|
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
|
|
|
|