| Author |
Message
|
| tillywern |
 Posted: Thu May 29, 2008 8:23 am Post subject: Queues set to NOTRIGGER after triggering. |
 |
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
Ok it has been a while since I have done triggering. Ok I have been in the dark ages of JMS without access to the beauty of MQ triggering. I wanted to show an example of a Java program using the native MQ API and triggering to my associates. The program serves a useful purpose in our development environment where clients do not always come and process all their messages.
To avoid using all our disk space I set up the client queues to be triggered on DEPTH. This way if a client is connected and getting their messages the trigger doesn't fire but if they turn off their processes over a weekend we don't use all our storage. The triggering works fine both with regard to when it fires, at the correct depth, and the calling of the desired program. The problem is that the queue is left with NOTRIGGER set when the program finished.
I don't recall having to have the called program reset the queue to TRIGGER when it is finished before. Perhaps my memory is rusty. Obviously that is a solution but a poor one. TRIGINT is set to the default eon but I don't think it is relevant here because my trigger type is DEPTH not FIRST and probably would not help since the queue ends up not set to trigger at all.
Did I forget something?
1 : dis ql(REMOVED) all
AMQ8409: Display Queue details.
QUEUE(REMOVED) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2008-05-29)
ALTTIME(15.40.34) BOQNAME( )
BOTHRESH(0) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) CLWLUSEQ(QMGR)
CRDATE(2008-05-01) CRTIME(15.33.2
CURDEPTH(1434) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFSOPT(SHARED) DEFTYPE(PREDEFINED)
DESCR( ) DISTL(NO)
GET(ENABLED) HARDENBO
INITQ(JAVA.INIT.QUEUE) IPPROCS(0)
MAXDEPTH(50000) MAXMSGL(4194304)
MONQ(QMGR) MSGDLVSQ(PRIORITY)
NOTRIGGER NPMCLASS(NORMAL)
OPPROCS(1) PROCESS(JAVA.CLEAR)
PUT(ENABLED) QDEPTHHI(80)
QDEPTHLO(20) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QDPMAXEV(ENABLED)
QSVCIEV(NONE) QSVCINT(999999999)
RETINTVL(999999999) SCOPE(QMGR)
SHARE STATQ(QMGR)
TRIGDATA( ) TRIGDPTH(1000)
TRIGMPRI(0) TRIGTYPE(DEPTH)
USAGE(NORMAL)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
$ dspmqver
Name: WebSphere MQ
Version: 6.0.2.0
CMVC level: p600-200-060921
BuildType: IKAP - (Production)
$ uname -a
SunOS hostname 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-480R |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu May 29, 2008 8:39 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It's an application responsibility to reset the trigger prior to exiting when DEPTH is used.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tillywern |
| Posted: Thu May 29, 2008 8:41 am Post subject: |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
Thanks. Yes I finally found the documentation. Application Programming Guide rather than the Application programming reference.
And yes. I am familiar with the manual but apparently not trigger type DEPTH |
|
| Back to top |
|
|
| exerk |
| Posted: Thu May 29, 2008 8:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It caught me out the first time I encountered it - it's now seared into what little bit of brain I have left 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Thu May 29, 2008 10:54 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
That's why the normal recommendation is to trigger on FIRST, and have the application hang around for a while and clear the queue.
It's much easier to manage using this approach.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
|
|
