| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Should the DLQ on a Queue Manager *must* be a local queue on |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqdev |
 Posted: Tue Mar 13, 2012 10:02 am Post subject: Should the DLQ on a Queue Manager *must* be a local queue on |
 |
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
We are attempting to consolidate the DLQs across the board in our enterprise, into a single Q (an Enterprise_DLQ if you will...). We have a mix of QMs on various platforms - Mainframe, various Unix flavours - Linux,AIX,Solaris etc., Windows, AS/400.... The idea was to configure the DLQ on the QM (set the DEADQ attribute on the QM) to that of the ENTERPRISE_DLQ which is a Cluster Q. All the QMs in the Enterprise are members of the Cluster. This approach, however does not seem to work when we tested it. I have tested this by setting up a simple Cluster with 4 QMs. On one of the QM, defined a QRemote to a non-existent QM and non-existent Q, but a valid xmitq and configure the requsite SDR chl between the QMs as follows:
QM_FR - Full_Repos QM1, QM2, QM3 - members of the Cluster
QM_FR hosts ENTERPRISE_DLQ which is advertised to the Cluster
On QM3 setup the following: QM3.QM1 - sdr to QM1, ql(QM1) with usage xmitq, qr(qr.not_exist) rqmname(not_exist) rname(not_exist) xmitq(qm1), setup QM1 to trigger-start QM3.QM1 when a msg arrives on QM1
On QM1: QM3.QM1 - rcvr chl, ql(local_dlq), ql(qa.enterise_dlq), qr(qr.enterprise.dlq)
Test 1: Set deadq on QM1 to ENTERPRISE_DLQ, write a msg to QR.NOT_EXIST on QM3 Result: Msg stays put on QM1, QM3.QM1 is RETRYING, QM1 error logs complain about not being able to MQOPEN the Q - ENTERPRISE_DLQ!!
ql(qm1) curdepth(1)
Test 2: Set deadq on QM1 to qr.enterprise.dlq, write a msg to QR.NOT_EXIST on QM3 Result: Msg stays put on QM1, QM3.QM1 is RETRYING, QM1 error logs complain about not being able to MQOPEN the Q - qr.enterprise.dlq (all caps)!!
ql(qm1) curdepth(2)
Test 3: Set deadq on QM1 to qa.enterise_dlq, write a msg to QR.NOT_EXIST on QM3 Result: Msg stays put on QM1, QM3.QM1 is RETRYING, QM1 error logs complain about not being able to MQOPEN the Q - qa.enterise_dlq (all caps)!!
ql(qm1) curdepth(3)
Test 4: Set deadq on QM1 to local_dlq, write a msg to QR.NOT_EXIST on QM3 Result: Msg stays put on QM1, QM3.QM1 is RUNNING, all msgs on QM3 ql(QM1) make it to local_dlq on QM3.
ql(qm1) curdepth(0)
Now the question: Looks like the DLQ on a QM must be a local queue. Is this a correct conclusion? If not, how can I make all the DLQs msg go to a single Q - Enterprise_DLQ above?
One obvious solution is to define a trigger on local_dlq on QM3 (and do the same on others QMs) which will read the msg and write it to the Cluster Q - ENTERPRISE_DLQ. But this involves additional moving parts - trigger, trigger monitor on each QM. It is most desirable to be able to configure a Cluster Q/QRemote/QAlias to be a DLQ on the QM. Thoughts/ideas???
Thanks
-mqdev |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Mar 13, 2012 10:08 am Post subject: Re: Should the DLQ on a Queue Manager *must* be a local queu |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdev wrote: |
I have tested this by setting up a simple Cluster with 4 QMs. On one of the QM, defined a QRemote to a non-existent QM and non-existent Q, but a valid xmitq and configure the requsite SDR chl between the QMs as follows:
QM_FR - Full_Repos QM1, QM2, QM3 - members of the Cluster |
This cluster is incorrectly set up. A WMQ cluster has 2, always 2 and only 2 FRs. This example only has 1 FR.
| mqdev wrote: |
| Now the question: Looks like the DLQ on a QM must be a local queue. Is this a correct conclusion? |
No it isn't.
| mqdev wrote: |
| If not, how can I make all the DLQs msg go to a single Q - Enterprise_DLQ above? |
You could start by building the cluster correctly.
I'd also question the wisdom of this design. If a DLQ is a local queue then you can be assured it's quickly and easily available. What's going to happen in your estate if a high volume process is trying to dead letter and there's a serious network delay? Or someone accidently unshares the enterprise DLQ from the cluster? Or changes the permissions on it?
Whatever you're using to monitor the health of your queue manager can easily monitor the depth of a local queue and report the arrival of a message to a central point. This is much the better solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 13, 2012 10:22 am Post subject: Re: Should the DLQ on a Queue Manager *must* be a local queu |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| A WMQ cluster has 2, always 2 and only 2 FRs. This example only has 1 FR. |
A cluster has at least two and at most two.
Neither shall you count to three.
One is okay, as long as you proceedeth to two thereafter.
But it has nothing to do with the issue at hand.
Presumably the necessary security was not configured to ensure that the necessary apps have the necessary permissions on the cluster xmit queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 13, 2012 10:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The Holy Hand Grenade of Antioch whilstles over my head and I dive for cover.
| mqjeff wrote: |
| Presumably the necessary security was not configured to ensure that the necessary apps have the necessary permissions on the cluster xmit queue. |
Good point, and IMHO another good reason not to do this. The fewer things which can write to the SCTQ the better.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqdev |
| Posted: Tue Mar 13, 2012 10:31 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Thanks Gentleman.
Vitor - with all due respect, the Cluster can function with a single FR. Only we wouldn't have redundancy for the Full Repository. We let this go with one as it was just a Lab setup to verify the concept. In actual prod implementation, we will have 2 FRs.
Coming to your critique of the approach - all very valid points Vitor. You are as usual - very thorough! For some reason, the Enterprise DLQ idea has gained traction and is the rage now. We are past the stage where we can question it now.
mqjeff - its not the security too - as we dont get a 2035 anywhere. As soon as I change the deadq on QM1 to point to a local Q on QM1, all is back to normal.
Thanks for you quick response - and please do keep writing.
-mqde |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 13, 2012 10:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The first thing is, as Vitor has suggested at least, you're really trying to do something that's not a recommended practice.
Consider the case where a receiver channel can't deliver a message. The receiver channel will then attempt to write the message to the DLQ. In the case where the DLQ is in fact not a qlocal, this means it will attempt to write the message to an XMITQ.
Now suppose that the reason the receiver was unable to deliver the message was because the message was being multi-hopped, and the destination xmitq was full... But the destination qmgr is the same qmgr that hosts the remote DLQ.... who's xmitq is full...
It is a useful and meaningful notion to centralize your management of DLQs. It is a recommended practice to do this by centralizing your MANAGEMENT of DLQs, not by centralizing your DLQs themselves.
Nothing says you can't modify the default dlq handler to be a client app and then read from remote DLQs and run several instances on a central machine. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 13, 2012 10:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It is also a recommended practice to force applications to rely on backout queues rather than on DLQs, and reserve DLQs for system level issues. |
|
| Back to top |
|
|
| mqdev |
| Posted: Tue Mar 13, 2012 10:52 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
mqjeff - thanks again. I am personally not a big fan of the Enterprise DLQ idea but am going with the flow instead of fighting it.
That said, am grappling with the issue that the Queue Manager seems to have been designed to work only with a "local" DLQ. Which is strange because DLQ setting on the QM is just a setting (deadq attribute - nothing is preventing us from specifying a Cluster Q/QRemote/QAlias - with all the attendent artifacts in place, off course). But implicitly, we seem to need a local Q for the DLQ.
Just for experimentation sake (forgeting for a minute if that is an intelligent course of action), could you implement a QM with a non-local queue for DLQ and make it work?
Thanks
-mqdev |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 13, 2012 11:07 am Post subject: Re: Should the DLQ on a Queue Manager *must* be a local queu |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqdev wrote: |
| Now the question: Looks like the DLQ on a QM must be a local queue. Is this a correct conclusion? If not, how can I make all the DLQs msg go to a single Q - Enterprise_DLQ above? |
No, this is an incorrect conclusion.
As to the first question: As with all other queue definitions, the object named in the DEADQ attribute of a qmgr must resolve to a local queue.
As to your second question: you could and should write a dead-letter handler script to move messages from the dead-letter queue to any queue on any queue manager you like.
_________________
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: Tue Mar 13, 2012 11:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdev wrote: |
| Just for experimentation sake (forgeting for a minute if that is an intelligent course of action), could you implement a QM with a non-local queue for DLQ and make it work? |
Windows, WMQv7.0.1.6, some dev queue managers I had pre-defined, tested by dead lettering a single message (i.e. hardly at all).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqdev |
| Posted: Tue Mar 13, 2012 11:19 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Bruce - thanks for your response.
Am a bit confused - when you say
"As to the first question: As with all other queue definitions, the object named in the DEADQ attribute of a qmgr must resolve to a local queue. ..."
Are you saying we should configure a "local" queue as the DLQ? Isn't that what I was concluding too - but you said it is not the right conclusion?
Can I do this:
Create QM1
alter qm1 deadq(qr.remoteqm.dlq)
def qr(qr.remoteqm.dlq) rqmname(remoteqm) rname(dlq) xmitq(<valid xmitq for remoteqm>
create sdr chl between qm1 & remoteqm
...
So when QM1 needs to put a msg to its DLQ, it puts it to QRemote( qr.remoteqm.dlq) which should eventually make it to the ql(dlq) on qm(remoteqm)
Thanks
-mqdev |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 13, 2012 11:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| mqdev wrote: |
| Just for experimentation sake (forgeting for a minute if that is an intelligent course of action), could you implement a QM with a non-local queue for DLQ and make it work? |
Windows, WMQv7.0.1.6, some dev queue managers I had pre-defined, tested by dead lettering a single message (i.e. hardly at all). |
Do you mean make it work in best-practice fashion? Or just make it work until it next breaks (see prior replies)?
_________________
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.
Last edited by bruce2359 on Tue Mar 13, 2012 11:30 am; edited 1 time in total |
|
| Back to top |
|
|
| mqdev |
| Posted: Tue Mar 13, 2012 11:26 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Gentlemen - on Linux (my lab setup), I cannot get the setup to work if I set the QM's deadq to a remote Q (Cluster Q/QRemote/QAlias pointing to a Cluster Q).
Vitor - did you set your Windows DLQ to be a remote Q?
Also where in Ohio are you - am in Columbus.
Thanks,
-mqdev |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 13, 2012 11:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Do you mean 'make it work in best-practice fashion? Or just make it work until it next breaks (see prior replies)? |
I meant "make it work" in the spirit of "just for experimentation" indicated by the OP.
I think I made my views on actually doing quite clear further up the thread. If I didn't, let me repeat them:
This is not a good idea or anything you should be doing. It is far better to centralize the reporting of dead lettered messages rather than the messages themselves.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Tue Mar 13, 2012 11:39 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 13, 2012 11:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqdev wrote: |
Gentlemen - on Linux (my lab setup), I cannot get the setup to work if I set the QM's deadq to a remote Q (Cluster Q/QRemote/QAlias pointing to a Cluster Q).
Vitor - did you set your Windows DLQ to be a remote Q?
Also where in Ohio are you - am in Columbus.
Thanks,
-mqdev |
What do you mean exactly that it didn't work? BE PRECISE.
_________________
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 |
|
|
|
|
|
  |
Goto page 1, 2, 3, 4, 5 Next |
Page 1 of 5 |
|
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
|
|
|
|
