| Author |
Message
|
| kalam475 |
 Posted: Fri Feb 03, 2017 8:44 am Post subject: |
 |
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
| Quote: |
| Please look at the MQ error logs - on BOTH client platform AND qmgr server platform? Any errors logged |
Here are the logs from WAS :
JMSWMQ2000: Failed to close queue 'mdbq'.
JMS attempted to close a WebSphere MQ destination, but encountered an error. The destination might already be closed, or another thread may be performing an MQGET while close() is called.
Use the linked exception to determine the cause of this error. You may be able to perform the close() later.:com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN').:com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009:com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009
Below is the relevent logs from the MQ server
AMQ7231: 10 log records accessed on queue manager 'CLUSQM1' during the recovery
phase.
EXPLANATION:
10 log records have been accessed so far on queue manager CLUSQM1 during the
recovery phase of the transactions manager state.
ACTION:
None.
-------------------------------------------------------------------------------
02/03/2017 04:34:45 AM - Process(16905.1) User(mqadmin) Program(amqzxma0)
Host(mq1.tec.com) Installation(Installation1)
VRMF(8.0.0.4) QMgr(CLUSQM1)
AMQ7232: Transaction manager state recovered for queue manager 'CLUSQM1'.
EXPLANATION:
The state of transactions at the time the queue manager ended has been
recovered for queue manager CLUSQM1.
ACTION:
None.
-------------------------------------------------------------------------------
02/03/2017 04:34:45 AM - Process(16905.1) User(mqadmin) Program(amqzxma0)
Host(mq1.tec.com) Installation(Installation1)
VRMF(8.0.0.4) QMgr(CLUSQM1)
AMQ7233: 0 out of 0 in-flight transactions resolved for queue manager
'CLUSQM1'.
EXPLANATION:
0 transactions out of 0 in-flight at the time queue manager CLUSQM1 ended have
been resolved.
ACTION:
None.
Even though if use the sync queue and and put the unique identifier in queue and read back from queue and in between if session is not able to roll back the message in queue.
In logs I have observed that session has been discontinued while switching .
Thanks |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Fri Feb 03, 2017 9:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
| In logs I have observed that session has been discontinued while switching . |
If a QMGR is being switched from one host to another (Active/passive) then there will be a short period of time when there are ZERO queue managers running.
So where do you think your application is going to connect to during that period?
A phantom QMGR perhaps
Seriously, getting a 2009 is what I'd ecpect when the QMGR is shutdown underneath me.
In clients that I have implemented in the past, I do a delayed reconnect. IF after a number of failures the QMGR is still not there, I terminate the application.
I'd also make the application a Windows service and make that service dependent upon MQ. That way, MSCS will handle it all for me.
If I got a 2009, I could just terminate knowing that MSCS would try to start the app again automatically.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Fri Feb 03, 2017 10:55 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
| Quote: |
| If a QMGR is being switched from one host to another (Active/passive) then there will be a short period of time when there are ZERO queue managers running. |
I do have a another queue manager in MQ cluster with this MI queue manager hosting the cluster queue with the same name as the queue in MI QMGR. If that is what you are saying.
The problem here is not to which queue manager it needs to connect to, my application is hitting producer.send() and then before commit happens my queue manager is switching state my message is in queue and when roll back is supposed to happen because of 2009 the session is lost while switching and I am getting a failed status even though the message in queue. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Feb 03, 2017 12:52 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
A 2009 message is CONNECTION LOST
That refers to the connection between your application and the QMGR not to the success or otherwise of your put operation.
The Queue Manager can't return a success or a failure to your application because ..... {drum roll} the connection between your application and the Queue manager is broken.
IF there is no way for the queue manager to send a success/failure message to the application then it can't. That is probably why you see the message on the queue but don't get a success message. There is probably a very small window where this could happen. Probaby a few microSeconds.
There are ways to get round this but these are probably NOT available withing a JMS framework.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Fri Feb 03, 2017 9:32 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
| Quote: |
| There are ways to get round this but these are probably NOT available withing a JMS framework. |
Is there is a workaround in MQ API, but I guess there is no way we can connect to connection factory through MQ API.
| Quote: |
There is probably a very small window where this could happen. Probaby a few microSeconds.
|
the problem here is messages are continiously coming and are enterprise application message cant afford to miss the message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 03, 2017 11:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kalam475 wrote: |
| Quote: |
| There are ways to get round this but these are probably NOT available withing a JMS framework. |
Is there is a workaround in MQ API, but I guess there is no way we can connect to connection factory through MQ API.
| Quote: |
There is probably a very small window where this could happen. Probaby a few microSeconds.
|
the problem here is messages are continiously coming and are enterprise application message cant afford to miss the message. |
Well if you can't afford to miss a message make sure of the following:
- All messages are persistent
- all send or receive operations happen within a unit of work
Note that on WAS and other J2EE servers the MDB defined Unit Of Work will supersede the settings coded when creating the JMSContext / JMS Session.
This should take care of most of your problems.
Test and let us know what you find out. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Feb 04, 2017 12:04 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| kalam475 wrote: |
the problem here is messages are continiously coming and are enterprise application message cant afford to miss the message. |
If you are failing over a QMGR then there will be a short window where the QMGR is just not available. That is a fact of life.
So how often will the QMGR be failed over?
- by Admin action
- by one system failing
The answer should be - very infrequently.
Some sites plan failovers every 1-2 months just to make sure that everything works.
This is often done when other systems are down for service/maintenance.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Sat Feb 04, 2017 10:04 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
| Quote: |
Well if you can't afford to miss a message make sure of the following:
All messages are persistent
all send or receive operations happen within a unit of work
Note that on WAS and other J2EE servers the MDB defined Unit Of Work will supersede the settings coded when creating the JMSContext / JMS Session.
This should take care of most of your problems. |
We are doing all of that.
1.messages are persistant
2.all the operations are in unit of work only
still there is still a possibility that message in queue and it just before my application does not gets the response the queue manager goes down.
We are thinking of raising a PMR and as said by @smdavies99 it is very rare but I guess we have to live with this failure scenario. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Feb 05, 2017 5:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| kalam475 wrote: |
| Quote: |
Well if you can't afford to miss a message make sure of the following:
All messages are persistent
all send or receive operations happen within a unit of work
Note that on WAS and other J2EE servers the MDB defined Unit Of Work will supersede the settings coded when creating the JMSContext / JMS Session.
This should take care of most of your problems. |
We are doing all of that.
1.messages are persistant
2.all the operations are in unit of work only
still there is still a possibility that message in queue and it just before my application does not gets the response the queue manager goes down.
We are thinking of raising a PMR and as said by @smdavies99 it is very rare but I guess we have to live with this failure scenario. |
What is the PMR for?
If you do a get of a persistent message with syncpoint right before a queue manager failover, once of the following will happen:
A. You get the message and commit, the commit has a MQRC 0, no issues.
-or-
B. You get the message and commit, the commit has a MQRC 2009, the connection may have failed before or after the commit failed or succeeded; so the message may or may not be there on the queue when you reconnect. Properly written apps are designed to handle duplicate messages.
-or-
C.You get the message but the MQRC for the MQGET is 2009 - the message will be on the queue when you reconnect.
There is no missing message in any of these scenarios.
New messages arriving from other queue managers will queue up in the transmission queues of those other queue managers until your QM's failover completes - no missing messages.
If other apps connect directly to this QM their MQPUTs and MQCMITs will fail during the failover, they should know their message may not have made it to the QM, no missing messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 05, 2017 6:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| kalam475 wrote: |
| Quote: |
| Please look at the MQ error logs - on BOTH client platform AND qmgr server platform? Any errors logged |
In logs I have observed that session has been discontinued while switching .
Thanks |
Why did you omit the actual error message associated with switching? Have you omitted anything else?
When I asked you to look at the error logs, I expected that you would post the related errors here for all to see. This is necessary for problem-source-identification.
Let me be more precise, in future posts please post all associated errors from all error logs.
_________________
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 |
|
|
|
|
