ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Failed to send a message to destination

Post new topic  Reply to topic Goto page Previous  1, 2, 3
 Failed to send a message to destination « View previous topic :: View next topic » 
Author Message
kalam475
PostPosted: Fri Feb 03, 2017 8:44 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Fri Feb 03, 2017 9:47 am    Post subject: Reply with quote

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
View user's profile Send private message
kalam475
PostPosted: Fri Feb 03, 2017 10:55 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Fri Feb 03, 2017 12:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
kalam475
PostPosted: Fri Feb 03, 2017 9:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Feb 03, 2017 11:01 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
smdavies99
PostPosted: Sat Feb 04, 2017 12:04 am    Post subject: Reply with quote

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
View user's profile Send private message
kalam475
PostPosted: Sat Feb 04, 2017 10:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Sun Feb 05, 2017 5:18 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
bruce2359
PostPosted: Sun Feb 05, 2017 6:16 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3 Page 3 of 3

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Failed to send a message to destination
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.