MQSeries.net :: View topic - DLQ Behaviour When DLQ Handler is being triggered !

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » DLQ Behaviour When DLQ Handler is being triggered !

Goto page Previous 1, 2, 3 Next

DLQ Behaviour When DLQ Handler is being triggered !

« View previous topic :: View next topic »

Author

Message

shashivarungupta

Posted: Thu Oct 13, 2011 1:21 pm Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

mqjeff wrote:

You have indicated that you manually executed the trigger monitor from a shell started by a logged in user.

Is this the same way that the trigger monitor normally gets started?

It depends !
But it could have been started at qmgr start, as a 'service' !!

_________________
*Life will beat you down, you need to decide to fight back or leave it.

bruce2359

Posted: Thu Oct 13, 2011 1:32 pm Post subject:

Poobah

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

shashivarungupta wrote:

It depends !
But it could have been started at qmgr start, as a 'service' !!

Was it started as a service? Or wasn't it? It could have been started by magic dust, too.
_________________
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.

shashivarungupta

Posted: Thu Oct 13, 2011 10:14 pm Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

bruce2359 wrote:

shashivarungupta wrote:

It depends !
But it could have been started at qmgr start, as a 'service' !!

Was it started as a service? Or wasn't it? It could have been started by magic dust, too.

Nope.. its was not started as service !!
By the way a trigger monitor was started manually way before first trigger happened ! Which kept on looking at initQ for any trigger mesg.
For instance, in this case of runmqdlq being triggered, if the trigger monitor is started manually Or using service at qmgr startup, what difference it could have made ?

I wish I had magic dust !!

_________________
*Life will beat you down, you need to decide to fight back or leave it.

shashivarungupta

Posted: Fri Oct 14, 2011 1:43 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

bruce2359 wrote:

The trigger monitor runs in a different shell - one that appears to have the WMQ bin folder in its execution path.

In your shell, does your path contain the WMQ bin folder (the one that contains runmqdlg)?

Yes. 'Path' variable contains wmq bin folder. (as shown below) and it has runmqdlq executable.

Quote:

Path=C:\Program Files\PC Connectivity Solution\;C:\Program Files\IBM\WebSphere MQ\Java\lib;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\IBM\Infoprint Select;C:\Notes;C:\Program Files\XLView;C:\lotus\compnent;C:\Utilities;C:\Program Files\IBM\Personal Communications\;C:\Program Files\IBM\Trace Facility\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\ThinkPad\ConnectUtilities;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL;C:\WINDOWS\system32\gs\gs8.71\bin;C:\Program Files\OpenSSH\bin;C:\Program Files\IBM\WebSphere MQ\bin;C:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin;c:\Program Files\Encentuate\AccessAgent\Integration\Carefx\Fusionfx;c:\Program Files\Encentuate\;C:\Program Files\IBM\WebSphere MQ\bin

But still I get the same error and find that there is one trigger message stuck in the initQ (even when the trig. monitor is ON). Trig msg is shown below !

Code:

00000 54 4D 20 20 01 00 00 00--44 45 41 44 51 20 20 20 |TM ....DEADQ |
00010 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00020 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00030 20 20 20 20 20 20 20 20--70 72 6F 63 31 20 20 20 | proc1 |
00040 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00050 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00060 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00070 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00080 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00090 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
000A0 20 20 20 20 20 20 20 20--0B 00 00 00 72 75 6E 6D | ...runm|
000B0 71 64 6C 71 20 3C 20 52--55 4C 45 54 45 53 54 2E |qdlq < RULETEST.|
000C0 52 55 4C 20 20 20 20 20--20 20 20 20 20 20 20 20 |RUL |
000D0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
000E0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
000F0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00100 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00110 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00120 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00130 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00140 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00150 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00160 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00170 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00180 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00190 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001A0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001B0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001C0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001D0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001E0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
001F0 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00200 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00210 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00220 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00230 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00240 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00250 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00260 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00270 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00280 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
00290 20 20 20 20 20 20 20 20--20 20 20 20 20 20 20 20 | |
002A0 20 20 20 20 20 20 20 20--20 20 20 20 | |

_________________
*Life will beat you down, you need to decide to fight back or leave it.

zpat

Posted: Fri Oct 14, 2011 2:06 am Post subject:

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Surely the DLQ handler is run as a service and listens to the DLQ queue all the time?

That's the way I use it.

shashivarungupta

Posted: Fri Oct 14, 2011 2:21 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

zpat wrote:

Surely the DLQ handler is run as a service and listens to the DLQ queue all the time?

That's the way I use it.

True, use DLQ Handler as a Service when DLQ is busy i.e. keep on getting some undelivered msgs in every expected intervals. Or Run dlq handler with wait(yes) which keeps on waiting for msgs to come to dlq to process them accordingly.. for a busy dlq.
BUT when I want, that my dlq is not busy, it's msgs should be handled whenever it comes to the dlq queue (not frequent), then I would opt for triggering the dlq handler with wait(nnn) in rule table. (that is what I'm trying here).

_________________
*Life will beat you down, you need to decide to fight back or leave it.

zpat

Posted: Fri Oct 14, 2011 3:31 am Post subject:

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Why not use an indefinite wait? This is very efficient. WAIT(YES).

BTW I define the service like this:

Quote:

DEFINE SERVICE('MY.DLQHANDLER') CONTROL(STARTONLY) SERVTYPE(SERVER) +
DESCR('Dead Letter Queue Handler') +
STARTCMD('+MQ_DATA_PATH+DLQ_start') +
STARTARG('+QMNAME+.DEAD.LETTER.QUEUE +QMNAME+ +MQ_DATA_PATH+DLQ_rules.txt') +
STDERR('+MQ_DATA_PATH+DLQ_stderr.txt') +
STDOUT('+MQ_DATA_PATH+DLQ_stdout.txt') +
REPLACE

shashivarungupta

Posted: Fri Oct 14, 2011 3:48 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

zpat wrote:

Why not use an indefinite wait? This is very efficient. WAIT(YES).

It would be efficient in case when system is very critical and undelivered msgs should be processed by dlq handler (based on rule table). Which keeps open the handle on DLQ !!
I have used this scenario as well on different servers !!
But that is not the actual question, why not use it with wait(yes).

Question is why 'runmqdlq < ruletable.rul' does not work when its mentioned in the appli id of process object (without giving the absolute path of mq utility or executable file which calls runmqdlq).
Why msg gets stuck in the initQ (msg is shown above in the previous post), which causes the loop of msgs to DLQ.

_________________
*Life will beat you down, you need to decide to fight back or leave it.

Mr Butcher

Posted: Fri Oct 14, 2011 4:00 am Post subject:

Padawan

Joined: 23 May 2005
Posts: 1716

in a first step, for testing, i would use a script with full pathname (so you know it is executed). the scripts function is to output the environment it is using. this maybe gives you a hint if runmqdlq without full path can work or not.

in addition, some of your paths inside the PATH statemant are written as PROGRA~1, but the MQ path you coded is C:\Program Files\IBM\WebSphere MQ\bin and not C:\Progra~1\IBM\WebSph~1\bin (or whatever it is in the 8.3 notation). But not sure if this makes a difference.
_________________
Regards, Butcher

zpat

Posted: Fri Oct 14, 2011 4:20 am Post subject:

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Keeping an open handle on a queue (for MQGET WAIT) is not really a waste of resources (unless you had thousands of these).

This is normal behaviour for most modern MQ applications (e.g. WMB). My DLQ is not busy, but it's no big deal either way.

mqjeff

Posted: Fri Oct 14, 2011 4:35 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

shashivarungupta wrote:

Question is why 'runmqdlq < ruletable.rul' does not work when its mentioned in the appli id of process object (without giving the absolute path of mq utility or executable file which calls runmqdlq).

Because when you run it as a service it does not have the wmq folder on the PATH.

Because the shell is different. Because the shell that launches the trigger monitor is different.

shashivarungupta

Posted: Mon Oct 17, 2011 5:26 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

mqjeff wrote:

shashivarungupta wrote:

Question is why 'runmqdlq < ruletable.rul' does not work when its mentioned in the appli id of process object (without giving the absolute path of mq utility or executable file which calls runmqdlq).

Because when you run it as a service it does not have the wmq folder on the PATH.

Because the shell is different. Because the shell that launches the trigger monitor is different.

I appreciate your response and can think that I might be doing that way.

But how can I feel that ? (i.e. How can I come to know that new shell is being launched? How can I trace it? Is that documented somewhere?).
I apologize for these questions but that would close the curiosity about this topic !

Thank you so much !
_________________
*Life will beat you down, you need to decide to fight back or leave it.

mqjeff

Posted: Mon Oct 17, 2011 6:25 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

As mentioned, this is mostly basic OS level stuff. talk to your local windows guru about what shell is in place when the IBM MQSeries Windows service, that runs the queue manager (presumably), that then runs the trigger monitor when started as an MQ service, that is then inherited by the command prompt that the trigger monitor issues to start your program..

Or alter your trigger to specify the full path to a .BAT file that contains a specific group of SET commands to define PATH and CLASSPATH and etc. to be able to find the program you need and ensure it has the shell level environment it needs.

shashivarungupta

Posted: Mon Oct 17, 2011 6:33 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

Thanks you all for your inputs that are much valuable as always.
Really appreciate it.

_________________
*Life will beat you down, you need to decide to fight back or leave it.

shashivarungupta

Posted: Mon Nov 21, 2011 5:57 am Post subject:

Grand Master

Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.

zpat wrote:

Quote:

I tried to do this way i.e. invoking dlq handler as server service object.(but for testing purpose I kept the control 'manual')

DEFINE SERVICE('dlqhandler') control(manual) servtype(server) descr('dlqhandler as server service') startcmd(runmqdlq) startarg('C:\Program Files\IBM\WebSphere MQ\bin\RULETEST.RUL') stdout('C:\varun\WMQStuff\Log.txt') stderr('C:\varun\WMQStuff\Err.txt')

where RULETEST.RUL is rule table as an argument to dlqhandler process which contains(I'm testing it on Windows, in rule table has 3rd line as blank line) :

Code:

INPUTQ('DEADQ') INPUTQM('RTEST') RETRYINT(45) WAIT(YES)
REASON(MQRC_Q_FULL) ACTION(FWD) FWDQ(DLQX) FWDQM(RTEST)

When I start this service, it gets started successfully (get logged in qmgr error log) and Ends (get logged in qmgr error log).

Standard Error text file contains (even when I made the Qmgr as Default queue manager on my machine & it has got default dlq 'DEADQ'):

Code:

11/21/2011 19:09:28 AMQ8741: Unable to connect to queue manager.
11/21/2011 19:09:28 AMQ8709: Dead-letter queue handler ending.

another scenario:
when I mention dlq name and qmgr in start argument then I get error "input in flex scanner failed" in standard error text file.
startarg(DEADQ RTEST 'C:\Program Files\IBM\WebSphere MQ\bin\RULETEST.RUL')

Please suggest !
_________________
*Life will beat you down, you need to decide to fight back or leave it.

Display posts from previous:

Goto page Previous 1, 2, 3 Next

Page 2 of 3

MQSeries.net Forum Index » General Discussion » DLQ Behaviour When DLQ Handler is being triggered !

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