| Author |
Message
|
| RicTicFL |
 Posted: Thu Jun 02, 2022 2:16 pm Post subject: FFST(FDC) thrown by MQClient Application |
 |
|
Newbie
Joined: 02 Jun 2022
Posts: 7
|
MQVersion 9.2
OS: AIX
Client J2SE app using MQJMS classes executing on ServerA
Connecting to MQServer executing on ServerB
Network connectivity issue occurs between servers
Result: FFST(FDC)s thrown on Client side (ServerA)
Is this expected behaviour?
My knowledge thus far is limited to seeing FFSTs thrown on Server-side only so this was a little unexpected.
Comments? |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Thu Jun 02, 2022 4:28 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Can you post the header of the FDC file? We may be able to offer some insight.
_________________
Glenn |
|
| Back to top |
|
|
| RicTicFL |
| Posted: Fri Jun 03, 2022 6:11 am Post subject: |
|
|
Newbie
Joined: 02 Jun 2022
Posts: 7
|
| gbaddeley wrote: |
| Can you post the header of the FDC file? We may be able to offer some insight. |
I am restricted from posting the FDC directly (originating from secure environment and all that).
What fields are you interested in exactly? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2022 8:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The first 50 lines or so will identify the MQ version, the ProbeID, failing component, and so on. There will no user data.
_________________
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 |
|
|
| RicTicFL |
| Posted: Fri Jun 03, 2022 9:33 am Post subject: |
|
|
Newbie
Joined: 02 Jun 2022
Posts: 7
|
| bruce2359 wrote: |
| The first 50 lines or so will identify the MQ version, the ProbeID, failing component, and so on. There will no user data. |
Be that as it may, I am prevented from directly posting. Here are snippets:
Java Vendor :- IBM Corporation
Java Version :- 2.9
Source Class :- WMQMessageConsumer
Source Method :- checkJmqiCallSuccess
ProbeID :- XN004008
Thread :- name=JMS-LISTENER[--maskedprogramname--] priority=5 group=main ccl=sun.misc.Launcher$AppClassLoader@7a971630
| comcode :-2
| hconn :- com.ibm.mq.jmqi.remote.impl.RemoteSession[--maskedSessionConnectionIdentifier--]
| inserts :-
| | XMSC_DESTINATION_NAME :- maskedQueueName
| messageId :- JMSWMQ2002
| reason :- 2018
IBM MQ JMS Provider
9.2.0.1 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2022 9:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Search google for the probe-ID, and/or open a PMR with IBM.
_________________
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 |
|
|
| RicTicFL |
| Posted: Thu Jun 09, 2022 4:54 am Post subject: |
|
|
Newbie
Joined: 02 Jun 2022
Posts: 7
|
| bruce2359 wrote: |
| Search google for the probe-ID, and/or open a PMR with IBM. |
I would still like to know whether throwing FDCs is an acceptable / expected behaviour for an MQ Client application |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 09, 2022 6:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| RicTicFL wrote: |
| bruce2359 wrote: |
| Search google for the probe-ID, and/or open a PMR with IBM. |
I would still like to know whether throwing FDCs is an acceptable / expected behaviour for an MQ Client application |
FDC’s Failure Data Capture capture data on unexpected errors. Are unexpected errors acceptable or expected? Yes and no.
Software is written by people, people make mistakes. Would you prefer such occurrences be suppressed (hidden from view)? IBM wants to gather as much failure data as possible to provide remediation in the form of PTFs, APAR FIXES, and new features and functions - for both server and client software.
It it helps, think of FDC's as equivalents of warning lights on your cars dashboard, namely that a warning or error has been detected, and that you should do something about 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 |
|
|
| hughson |
| Posted: Thu Jun 09, 2022 8:50 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| RicTicFL wrote: |
| comcode :-2
| hconn :- com.ibm.mq.jmqi.remote.impl.RemoteSession[--maskedSessionConnectionIdentifier--]
| inserts :-
| | XMSC_DESTINATION_NAME :- maskedQueueName
| messageId :- JMSWMQ2002
| reason :- 2018
IBM MQ JMS Provider
9.2.0.1 |
In addition to what others have said, all of which I agree with, looking at this specific error, we can see that the MQ Reason code is 2018 MQRC_HCONN_ERROR. This suggests a code path has been taken without a successful MQCONN, where the hConn that would have been returned from a successful MQCONN being used when it isn't valid. This is certainly the sort of thing that shouldn't happen and should definitely be reported to IBM for correction.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Jun 11, 2022 10:57 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I've seen MQRC 2018 where the MQ client application has attempted a MQCONN which failed (for whatever reason) but the application merrirly carried on and attempted to MQOPEN without a valid connection handle.
If I had to bet on whether it was IBM code or application code not checking the handle was valid - my money would be on the application.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Jun 12, 2022 10:37 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| zpat wrote: |
I've seen MQRC 2018 where the MQ client application has attempted a MQCONN which failed (for whatever reason) but the application merrirly carried on and attempted to MQOPEN without a valid connection handle.
If I had to bet on whether it was IBM code or application code not checking the handle was valid - my money would be on the application. |
While that is generally true, for JMS applications, which is what is surfacing the FDC in this case, the handles are not available to the application and so it cannot make this error. The error must, it seems, be in the JMS code from IBM.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
