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 IndexClusteringShould the DLQ on a Queue Manager *must* be a local queue on

Post new topicReply to topic Goto page Previous  1, 2, 3, 4, 5  Next
Should the DLQ on a Queue Manager *must* be a local queue on View previous topic :: View next topic
Author Message
bruce2359
PostPosted: Tue Mar 13, 2012 11:33 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7862
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Mar 13, 2012 11:39 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24648
Location: Ohio, 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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 13, 2012 11:44 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24648
Location: Ohio, 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
View user's profile Send private message
mqdev
PostPosted: Tue Mar 13, 2012 11:54 am Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 13, 2012 12:05 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24648
Location: Ohio, 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
View user's profile Send private message
mqdev
PostPosted: Tue Mar 13, 2012 12:11 pm Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 13, 2012 12:15 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24648
Location: Ohio, 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
View user's profile Send private message
mqjeff
PostPosted: Tue Mar 13, 2012 12:24 pm Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17448

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
View user's profile Send private message
mqdev
PostPosted: Tue Mar 13, 2012 1:00 pm Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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) wouldnt 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
View user's profile Send private message
bruce2359
PostPosted: Tue Mar 13, 2012 1:39 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7862
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) wouldnt 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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Mar 13, 2012 1:58 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7381

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc10620_.htm

Quote:

DEADQ(string)
The local name of a dead-letter queue (or undelivered-message queue) on which messages that cannot be routed to their correct destination are put.
The queue named must be a local queue.

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Mar 13, 2012 2:56 pm Post subject: Re: Should the DLQ on a Queue Manager *must* be a local queu Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7862
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Mar 13, 2012 9:40 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19432
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
View user's profile Send private message Send e-mail
mqdev
PostPosted: Wed Mar 14, 2012 6:46 am Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
bruce2359
PostPosted: Wed Mar 14, 2012 6:59 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7862
Location: US: west coast, almost. Otherwise, enroute.

Did you research ReasonCode 2082? You could google 'mqrc 2082'.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3, 4, 5  Next Page 2 of 5

MQSeries.net Forum IndexClusteringShould the DLQ on a Queue Manager *must* be a local queue on
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.