| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CLUSTER CHANNEL ISSUE |
« View previous topic :: View next topic » |
| Author |
Message
|
| gag_nm |
 Posted: Sun Apr 18, 2010 9:27 pm Post subject: CLUSTER CHANNEL ISSUE |
 |
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
Hello ,
i have some interesting issue,
we have two QMGR's QMA and QMB as full repository and QMC as partial repository .
we made TEST.IN as Cluster queue which resides at both full repository queue manager(QMA and QMB) for load sharing .TEST.IN has backout queue TEST.IN.BACKOUT
Issue is when we restart QMC queuemanager ,request which comes from QMC in going to TEST.IN.BACKOUT.
i feel the issue is with channel level conversation issue, we made channel level conevrsation as YES.
to make work from QMC, i use to run below command
REFRESH CLUSTER(CLSMQ) REPOS(YES)
after running above command, it works fine.
can some help me  Even if i restart QMC ,it should work fine with out executing Refresh command under QMC.
please find the below scripts executed at QMC.
DEFINE CHANNEL ('QMA.CH') CHLTYPE(CLUSSDR) +
CLUSTER('CLSMQ') +
CLUSNL(' ') +
CONNAME('XXX.XXX.XXX.XXX(XXXX)') +
LOCLADDR(' ') +
CONVERT(YES) +
DESCR('Cluster Sender') +
REPLACE
DEFINE CHANNEL ('QMB.CH') CHLTYPE(CLUSSDR) +
CLUSTER('CLSMQ') +
CLUSNL(' ') +
CONNAME('XXX.XXX.XXX.XXX(XXXX)') +
LOCLADDR(' ') +
CONVERT(YES) +
DESCR('Cluster Sender') +
REPLACE
DEFINE CHANNEL ('QMC.CH') CHLTYPE(CLUSRCVR) +
CLUSTER('CLSMQ') +
CLUSNL(' ') +
CONNAME('XXX.XXX.XXX.XXX(XXXX)') +
LOCLADDR(' ') +
CONVERT(NO) +
DESCR('MQ Cluster Receiver') +
REPLACE |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Sun Apr 18, 2010 10:42 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
IMHO its better if the application uses get convert options, istead of using convert on the channel, especially on clsuter channels.
on qmc, the explicit defined cluster sender channels are defined with CONVERT(YES). But these channels are only used for initial contact to the FR. After contacting the FR, these give their cluster receiver channel definitions to QMC making QMC to build its implicit defined cluster sender channels from that.
after that, when the cluster sender channel is started again (e.g. after a qmgr restart), the implicit defined cluster sender channels are used. now, if you do not have defined the clsuter receiver channels on the FR with convert(yes), you will run without conversion from that point in time on.
if you use the clsuter refresh, you will dump the implicit defined channels and use the explicit defined again, thats why conversion works from that time on.
either define all channels (cluster sender and cluster receiver( with convert(yes), or none and let the application do the convert.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 19, 2010 5:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| TEST.IN has backout queue TEST.IN.BACKOUT |
Backout requeue queue name is a queue attribute. WMQ takes no action based on this attribute.
| Quote: |
| Issue is when we restart QMC queuemanager ,request which comes from QMC in going to TEST.IN.BACKOUT. |
Since WMQ takes no action on the backout requeue queue name, one of your applications must be moving the message to the backout queue.
| Quote: |
| i feel the issue is with channel level conversation issue, we made channel level conevrsation as YES. |
What qmgr error message(s)or documentation led you to believe that a conversion failure would lead to the message being sent to a backout queue?
_________________
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 |
|
|
| Vitor |
| Posted: Mon Apr 19, 2010 6:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
One good question is why you changed the cluster channels to CONVERT(YES) - what were you trying to achieve?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gag_nm |
| Posted: Mon Apr 19, 2010 9:23 pm Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
First thanks to all your suggestions and Questions.
To Mr Butcher
| Quote: |
| cluster sender and cluster receiver( with convert(yes) |
i changed property of receiver channel to CONVERT(YES), then i restarted QMC ,even then request was going to backout queue.
To bruce2359
| Quote: |
| What qmgr error message(s)or documentation led you to believe that a conversion failure would lead to the message being sent to a backout queue? |
as i already told you regarding this.
if CONVERT(YES) it works fine,if CONVERT(NO) it was going to back out queue in broker.please find below execption trace from broker.
| Quote: |
( ['MQROOT' : 0x1129ebaf0]
(0x01000000:Name):RecoverableException = (
(0x03000000:NameValue):File = '/build/S610_P/src/DataFlowEngine/ImbMqInputNode.cpp' (CHARACTER)
(0x03000000:NameValue):Line = 2005 (INTEGER)
(0x03000000:NameValue):Function = 'ImbCommonInputNode::eligibleForBackout' (CHARACTER)
(0x03000000:NameValue):Type = 'ComIbmMQInputNode' (CHARACTER)
(0x03000000:NameValue):Name = 'MQService#FCMComposite_1_1' (CHARACTER)
(0x03000000:NameValue):Label = 'Service.Dispather' (CHARACTER)
(0x03000000:NameValue):Catalog = 'BIPv610' (CHARACTER)
(0x03000000:NameValue):Severity = 3 (INTEGER)
(0x03000000:NameValue):Number = 2652 (INTEGER)
(0x03000000:NameValue):Text = 'Dequeued failed message. Propagating a message to the failure terminal' (CHARACTER)
)
) |
To Vitor
| Quote: |
| One good question is why you changed the cluster channels to CONVERT(YES) - what were you trying to achieve? |
intially we created channels with CONVERT(NO),it was failing in broker and message was reaching backout, Luckly we changed CONVERT(NO) to CONVERT(YES), it started working fine with out failing at broker. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 20, 2010 5:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
as i already told you regarding this.
if CONVERT(YES) it works fine,if CONVERT(NO) it was going to back out queue in broker.please find below execption trace from broker. |
Apparently you do have an application running that causes the msg to go to the backout queue - the broker.
The symptom you are experiencing is from attempted and failed data conversion. The symptom arises from your setting CONVERT(YES) on your channel definition AND the subsequent failure of data conversion, NOT because of the channel setting.
There is much in the WMQ APR and APG manuals about data conversion, and when data conversion can fail.
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Apr 20, 2010 5:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
DO NOT SET CONVERT(YES) ON CLUSTER CHANNELS.
Broker automatically handles data conversion. If the message is going to the backout queue it is because the data in the message is bad, not because it has been improperly converted.
Troubleshoot the Broker error at the Broker level, NOT at your MQ Cluster level.
All that trace segment shows is that the message has already been retried in the flow more times than BOTHRESH() on the queue being read from the MQInput node. It shows you nothing about WHY the message has been retried.
Troubleshoot your broker flow and the sending application to make sure it is not sending bad data (it's very very likely the sending application is sending bad data!) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 20, 2010 9:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
DO NOT SET CONVERT(YES) ON CLUSTER CHANNELS.
|
 and would even go as far as to say that if you don't ABSOLUTELY NEED channel conversion, it is a bad idea to set it at all.
I've had the case where it severely messed with messages in a multihop scenario... Removed the conversion on the channel and the multihop scenario played out nice....
That said all advice from mqjeff is excellent... follow it! 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
