| Author |
Message
|
| blueman |
 Posted: Mon May 24, 2010 4:15 am Post subject: Reponse fails with MQJE001: Completion Code 2, Reason 2019 |
 |
|
Novice
Joined: 23 May 2010
Posts: 15
|
Hi,
I have a Message Flow which sends a request to an external application, When the application reply to broker, it fails with an error MQJE001: Completion Code 2, Reason 2019.This happens only on the first request which is been triggered after a long intervel, the subsequent requests get through. We have a MQ clustered environment.
Further my investigation throgh the event logs i found that there is a MQCMIT is been sent from the external application and a disconnection is recorded within the windows event log.Furthermore within a Windows system where a MQRC_CONNECTION_BROKEN event is recorded with a completion code of MQCC FAILED (code=2) this is an indication that a successful MQCMIT command has been received and committed.
Any help is appreciated
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon May 24, 2010 4:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Sounds like what the error says; the external application's been sitting on an idle connection for a while, the queue manager's assumed the connection is unused but not closed and closed it.
If the external application is going to be idle for a period then be triggered, the accepted design is for it to shut down (and close the connection) and reopen a new one when it restarts.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 24, 2010 4:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
Sounds like what the error says; the external application's been sitting on an idle connection for a while, the queue manager's assumed the connection is unused but not closed and closed it.
|
Queue Managers don't make those assumptions. It would be bad if QMs were closing connections when they felt like it.
I'm unaware of any setting that tells a QM to kill an otherwise valid connection to a queue just because it has been idle (other than the ClientIdle environment variable for MQ Client connections to the queue manager.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 24, 2010 4:31 am Post subject: Re: Reponse fails with MQJE001: Completion Code 2, Reason 20 |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| blueman wrote: |
| Furthermore within a Windows system where a MQRC_CONNECTION_BROKEN event is recorded with a completion code of MQCC FAILED (code=2) this is an indication that a successful MQCMIT command has been received and committed. |
How do you know the connection didn't break before the MQCMIT was received by the QM?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| blueman |
| Posted: Mon May 24, 2010 5:34 am Post subject: |
|
|
Novice
Joined: 23 May 2010
Posts: 15
|
| is MQCMIT a property or any configuration that need to be done in message flows or in the Queue Manager? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 24, 2010 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blueman wrote: |
| is MQCMIT a property or any configuration that need to be done in message flows or in the Queue Manager? |
Neither, nor. MQCMIT is a command that tells the qmgr to commit the current UOW associated with that handle. It can be issued by any application having an open UOW. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blueman |
| Posted: Mon May 24, 2010 7:26 am Post subject: |
|
|
Novice
Joined: 23 May 2010
Posts: 15
|
| Quote: |
| Neither, nor. MQCMIT is a command that tells the qmgr to commit the current UOW associated with that handle. It can be issued by any application having an open UOW. |
So where is this command triggered from ? the external application or the broker in my case?
thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 24, 2010 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hard to tell as it looks like you have applications accessing the broker qmgr.
In the flows you can configure the MQOutput node and tell it whether or not it participates in the current transaction (See MQOuput Properties).
If your client uses transacted calls it's up in the air as to which call is causing the problem without more investigation...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 24, 2010 10:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Neither, nor. MQCMIT is a command that tells the qmgr to commit the current UOW associated with that handle. It can be issued by any application having an open UOW
I'm guessing that you didn't mean this literally. It is possible to MQCMIT not having any puts/gets or anything else needing commiting or backing out.
From the InfoCenter:
The MQCMIT call indicates to the queue manager that the application has reached a syncpoint, and that all the message gets and puts that have occurred since the last syncpoint are to be made permanent.
From me: if any.
_________________
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 |
|
|
| blueman |
| Posted: Mon May 24, 2010 10:53 am Post subject: |
|
|
Novice
Joined: 23 May 2010
Posts: 15
|
| Quote: |
| How do you know the connection didn't break before the MQCMIT was received by the QM? |
I mean for the subsequent request i recieved a reply from the external application. So the connection was not broke.
thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 24, 2010 11:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Which application is it that is receiving the MQRC 2019?
That is the application that is having an issue. No other application is implicated.
If the replying application receives a 2019 trying to send a reply, it should create a new connection and attempt to resend the same reply. If it is not doing that, then it is not written correctly.
If the replying application receives a 2019 trying to issue an MQCMIT then it needs to determine how to respond based on the business requirements. This can include rolling back any related transactions and retrying the connection, or it can include attempting to send another reply that indicates that the request failed or any number of other things.
If a requesting application doesn't receive a reply to some specific request, it needs to take the appropriate action for the business logic - either resend the request or raise an alert or notify an end user somehow. |
|
| Back to top |
|
|
|
|
