Author |
Message
|
bruce2359 |
Posted: Tue Mar 13, 2012 11:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9399 Location: US: west coast, almost. Otherwise, enroute.
|
Vitor wrote: |
I think I made my views on actually doing quite clear further up the thread. |
Yes, but you appeared to soften a bit. _________________ 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:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqdev wrote: |
Vitor - did you set your Windows DLQ to be a remote Q? |
Yes, I thought that was what we were talking about.
mqdev wrote: |
Also where in Ohio are you - am in Columbus. |
Cleveland. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
Vitor |
Posted: Tue Mar 13, 2012 11:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
bruce2359 wrote: |
Vitor wrote: |
I think I made my views on actually doing quite clear further up the thread. |
Yes, but you appeared to soften a bit. |
Me, soften? It's been a while since I've been accused of that.
This is not a good idea; there are a number of points where it can break, many of which have been enumerated in this thread. Even if the idea does have "traction", the OP should get in front of this and at least make sure whoever manages the business risk is aware that, while the train may have left the station it could easily derail down the line.
(Railway enthusiasts should note the use of the word "traction" and be impressed. Or not. Yes, the coffee machine is broken.) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
mqdev |
Posted: Tue Mar 13, 2012 11:54 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003 Posts: 136
|
Alright Gentlemen – here is my definition of “making it to work”:
Setup the deadq attribute on the QM to point to a remote Q, make a msg go to the DLQ on the QM and check if the msg indeed goes to the remote Q (which is configured as the DLQ via the deadq attribute).
I have tried the setup as described in OP and could not get the msg go to the configured DLQ unless the DLQ is local to the QM. Specifically if I configure the deadq to point to a Cluster Q or QAlias locally defined, but pointing to Cluster Q (target = Cluster Q), the message that is supposed to go to DLQ stays put on the xmitq and the chl goes into a RETRY state. The chl goes to RUNNING state and msgs on the xmitq clearup, only after I change the deadq to point to a local Q.
Thanks
-mqdev |
|
Back to top |
|
|
Vitor |
Posted: Tue Mar 13, 2012 12:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
So you go back to whoever's pushing this idea & say:
"Right, done a proof of concept & it's clear to me the software doesn't support this configuration. Tell the monitoring team we need them to extend the queue depth moniting they already have to stop the business queues filling to include the dead letter queue".
So much for that train. Simples. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
mqdev |
Posted: Tue Mar 13, 2012 12:11 pm Post subject: |
|
|
Centurion
Joined: 21 Jan 2003 Posts: 136
|
Actually there is a bit of history to this - some of which unfortunately confidential. From historical perspective, this does make sense - though the approach is far from perfect. What is more, the pain points in this approach are lesser then the pains otherwise and hence we are going down this path.
No we wouldn't want to setup a mechanism to collect the msgs in the local DLQ and run individual jobs to move the msgs to the Central DLQ - as that again is a point of failure! We would rather let MQ do the stuff by configuring a Cluster Q as the DLQ on each QM and/or a QAlias.
Alas it wasn't to be that way as it appears the DLQ on a QM must & should be a local Q on the QM (unless someone refutes that!)
Thanks
-mqdev |
|
Back to top |
|
|
Vitor |
Posted: Tue Mar 13, 2012 12:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqdev wrote: |
From historical perspective, this does make sense - though the approach is far from perfect. What is more, the pain points in this approach are lesser then the pains otherwise and hence we are going down this path. |
Your history must be interesting. Believe me, the pain points would have hurt you going forwards with this.
mqdev wrote: |
Alas it wasn't to be that way as it appears the DLQ on a QM must & should be a local Q on the QM (unless someone refutes that!) |
Not must (except on your installation thankfully) but certainly should. So everyone's happy & the working day slides into a golden sunset.
(Yes, coffee machine still out of action. Starbucks on the way home.) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
mqjeff |
Posted: Tue Mar 13, 2012 12:24 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
mqdev wrote: |
No we wouldn't want to setup a mechanism to collect the msgs in the local DLQ and run individual jobs to move the msgs to the Central DLQ - as that again is a point of failure! We would rather let MQ do the stuff by configuring a Cluster Q as the DLQ on each QM and/or a QAlias. |
Again, the recommended practice is you should NOT move messages to a central DLQ, either manually or through MQ channels. The recommended practice is that you should set up jobs to process each DQL remotely, and have those jobs deliver messages to queues relevant to the connected queue manager.
mqdev wrote: |
Alas it wasn't to be that way as it appears the DLQ on a QM must & should be a local Q on the QM (unless someone refutes that!) |
Vitor has already shown that it is possible to configure a QM with a non-local DLQ.
And for grins, I have deleted the qlocal S.D.L.Q on one of my qms, and created it as a QREMOTE naming both an RQMNAME and an XMITQ. I was then able to start a sender channel.
So it is not clear that you have proven that your desired setup is not possible. |
|
Back to top |
|
|
mqdev |
Posted: Tue Mar 13, 2012 1:00 pm Post subject: |
|
|
Centurion
Joined: 21 Jan 2003 Posts: 136
|
Let me try this one last time folks:
Here is the setup:
1. QM_FR – FR and also hosts ENTERPRISE_DLQ advertised to the Cluster
2. QM1, QM2 & QM3 PRs in the Cluster
On QM3:
3. Def qr(qr.not_exist) rqmname(not_exist) rname(not_exist)
4. Def sdr(qm3.qm1) chltype(sdr) conname(<valid>) xmitq(qm1)
5. Def ql(qm1) usage(xmitq)
6. Alter ql(qm1) to trigger the sdr chl QM3.QM1 when there is a msg on qm1
On QM1:
7. Alter qmgr deadq(enterprise_dlq) / Alter qmgr deadq(qa.enterprise_dlq) /alter qmgr deadq(local_dlq)
8. Def chl(qm3.qm1) chltype(rcvr)
9. Def ql(local_dlq)
10. Def qa(qa.enteprise_dlq) target(enterprise_dlq)
Now write a msg on QR.NOT_EXIST on QM3:
amqsput QR.NOT_EXIST QM3.
Here is the expected result:
a) The xmitq in QR.NOT_EXIST is QM1. The message put through amsput will hit QM1 Q on QM3.
b) Since the xmitq is configured to trigger the SDR chl QM3.QM1, the SDR chl should start up.
c) Msg gets to QM1. Since QM1 has no knowledge about QM NOT_EXIST and Q NOT_EXIST (this is what we have configured in the QRemote on QM3 – see definition bullet point #3 above), QM1 will attempt to dump the msg in its DLQ.
Here is what actually happens:
the SDR in (b) above, fails to startup.
i.e. the SDR from QM3 to QM1 (QM3.QM1) wouldn’t startup – it goes into RETRYING status and the message stays put on xmitq QM1 on QM3.
Ditto result if I change the deadq attribute on QM1 to point to qa.enterprise_dlq (see bullet #7 above)
How to get it to work:
Change the deadq on QM1 to local_dlq.
This delights the Queue Manager QM1 – the sdr chl QM3.QM1 is now RUNNING, and the messages on xmitq QM1 on QM3 now drain and the messages end up on the ql(local_dlq) on QM3.
So the conclusion is:
the DLQ on a QM **must & should ** be a local Q on the same QM. It cannot be a Cluster Q known to the QM or QRemote/QAlias defined on the QM. Case rested. |
|
Back to top |
|
|
bruce2359 |
Posted: Tue Mar 13, 2012 1:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9399 Location: US: west coast, almost. Otherwise, enroute.
|
mqdev wrote: |
On QM1:
7. Alter qmgr deadq(enterprise_dlq) / Alter qmgr deadq(qa.enterprise_dlq) /alter qmgr deadq(local_dlq)
Let me try this one last time folks:
the SDR in (b) above, fails to startup.
i.e. the SDR from QM3 to QM1 (QM3.QM1) wouldn’t startup – it goes into RETRYING status and the message stays put on xmitq QM1 on QM3.
|
As to 7. above: why alter the deadq attribute 3 times??
Let me ask you one last time: exactly why did the channel go into RETRYING? What did you discover in the error logs AT BOTH ENDS OF THE CHANNEL? _________________ 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 |
|
|
PeterPotkay |
Posted: Tue Mar 13, 2012 1:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7716
|
|
Back to top |
|
|
bruce2359 |
Posted: Tue Mar 13, 2012 2:56 pm Post subject: Re: Should the DLQ on a Queue Manager *must* be a local queu |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9399 Location: US: west coast, almost. Otherwise, enroute.
|
mqdev wrote: |
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)!!
|
In future posts, please be precise.
Error logs don't complain. Rather, they log precise errors, with error messages and reason codes, useful for problem determination. _________________ 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 |
|
|
fjb_saper |
Posted: Tue Mar 13, 2012 9:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20696 Location: LI,NY
|
Does putting any message on your QA/QR/QC that you intend to be using as DLQ work? If not what is the reason code?
Have fun _________________ MQ & Broker admin |
|
Back to top |
|
|
mqdev |
Posted: Wed Mar 14, 2012 6:46 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003 Posts: 136
|
Peter - you hit the nail on the head! I did read through the manual but missed the text you highlighted in red! Thanks buddy for pointing it out to me! I seem to have learnt it the hard way that the DLQ must be a local Q on the QM!
--------------
fjb_saper - qa/qc/qr work as expected in the Cluster/QM. However the issue here is for the msgs to get to the QM (QM1 in this case).
--------------
bruce:
I changed deadq thrice
1. to point it to a Cluster Q (ENTERPRISE_DLQ) known to the QM
2. to point it to a local object - QAlias which points to the Cluster Q
3. to point it to a truely local Q - local_dlq
If you read through my last post - these are the tests I did to check if my setup "works" - again please read through my earlier posts as to what I precisely mean by "works".
Error msgs in QM logs on QM1:
EXPLANATION:
The attempt to open either the queue or queue manager object 'LOCAL.QA.TO.CLDQ' on queue manager 'QM1' by user '' failed with reason code 2082.
ACTION:
Ensure that the queue is available and retry the operation. If the message is from a remote Queue Manager, check the Message Channel Agent User Identifier has the correct authority.
Here is how LOCAL.QA.TO.CLDQ id defined on QM1:
dis qa(loca*) all
1 : dis qa(loca*) all
AMQ8409: Display Queue details.
QUEUE(LOCAL.QA.TO.CLDQ) TYPE(QALIAS)
ALTDATE(2012-03-12) ALTTIME(11.35.26)
TARGET(ENTERPRISE_DLQ) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFPRESP(SYNC) DEFREADA(NO)
DESCR( ) GET(ENABLED)
PUT(ENABLED) PROPCTL(COMPAT)
SCOPE(QMGR) TARGTYPE(QUEUE)
ENTERPRISE_DLQ is my Cluster DLQ
----------
Once again, thanks everybody for your time.
-mqdev
Last edited by mqdev on Wed Mar 14, 2012 7:00 am; edited 1 time in total |
|
Back to top |
|
|
bruce2359 |
Posted: Wed Mar 14, 2012 6:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9399 Location: US: west coast, almost. Otherwise, enroute.
|
Did you research ReasonCode 2082? You could google 'mqrc 2082'. _________________ 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 |
|
|
|