| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Sep 14, 2006 6:54 am Post subject: |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
you're right Jeff, type=EVERY is not very good either.
So I'm back to attempting to get this scheme to work with type=DEPTH.
I'll have to
#1. parse the TMC2 to produce qName and qmgrName (these automatically supplied by the trigger monitor)
#2. invoke amqsbcg with qName and qmgrName arguments
#3. runmqsc to turn triggering back on for the queue
Do you happen to have example KSH for parsing the TMC2? I've been looking through awk,grep,egrep,sed, etc looking for some easy/robust way of doing this but coming up short so far. One problem is that the TMC2 structure starts out with "TMC 2" immediately followed by the QNAME. It looks like I'd have to hard code a length to get around the structid and version. |
|
| Back to top |
|
 |
| scottm |
| Posted: Thu Sep 14, 2006 12:35 pm Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
So - are some of the receipts possibly not going to be read? But some might be read?
If you set the expiry on the messages, my understanding is that if anything reads the queue, all the expired messages will be removed.
So - if another client will read the queue, then all expired messages will be disgarded. And isn't that what you want?
Why bother trying to read the queue yourself, just wait until some other client reads it and then your expired messages will be gone. If no one is going to read the receipts at all, why bother saving them - but as long as one client reads them, you should be good. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 14, 2006 12:51 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Scott,
The core app is an ESB. It is required to publish receipts for every Business Event message passed through the bus. Clients of the ESB would dequeue the event receipts if they were properly designed. The design of the ESB client applications is beyond the political scope of the ESB development team. These facts lead to a situation in which we are publishing messages to a queue for which there are 0 consumers. Here enters this ridiculous expiry scheme. The idea is to set MQMD.expiry and then to trigger a browse program on depth.
My remaining technical challenge for this approach is related to the need to KSH parse the MQTMC2 structure to glean both queueName and qmgrName for use as parameters to amqsbcg.
jd |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 14, 2006 3:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ivanachukapawn wrote: |
Scott,
The core app is an ESB. It is required to publish receipts for every Business Event message passed through the bus. Clients of the ESB would dequeue the event receipts if they were properly designed. The design of the ESB client applications is beyond the political scope of the ESB development team. These facts lead to a situation in which we are publishing messages to a queue for which there are 0 consumers. Here enters this ridiculous expiry scheme. The idea is to set MQMD.expiry and then to trigger a browse program on depth.
My remaining technical challenge for this approach is related to the need to KSH parse the MQTMC2 structure to glean both queueName and qmgrName for use as parameters to amqsbcg.
jd |
No need if you run on Version 6 of MQ. There seems to be a part of MQ that cleans up expired messages periodically.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Fri Sep 15, 2006 3:49 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
FJB,
That's extremely interesting (that --> a feature of MQ6 which removes expired messages from queues). I will setup a test to verify that this actually happens. In the meanwhile, could you point me to the documentation which indicates that this feature exists?
Thanks,
Ivana |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Sep 18, 2006 6:43 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Here is ksh code which uses patterns to parse the mqtrmc2 structure gleaning queueName and queueManagerName. The script then continues to run amqsbcg which browses the queue and removes the expired messages. Then it creates a command file and runs runmqsc to turn the trigger control back on.
Note: This turned out to be just a useless exercise because the gentlemen who posted that MQ6.0 has a feature which automatically removes expired messages IS CORRECT! MQ6.0 takes care of this problem automatically.
!/bin/ksh
##########################################################
# REMOVE THE LEADING MQTRMC2 HEADER INFO (ID and VERSION)
##########################################################
removedIDver=${1#*2}
##########################################################
# PATTERN MATCH TO YIELD queueName
##########################################################
queueName=${removedIDver%% *}
##########################################################
# PATTERN MATCH TO YIELD queueManagerName
##########################################################
queueManagerName=${removedIDver##*\&}
##########################################################
# BROWSE THE QUEUE (THIS WILL REMOVED EXPIRED MESSAGES)
##########################################################
/opt/mqm/samp/bin/amqsbcg $queueName $queueManagerName
##########################################################
# CREATE AN MQSC COMMAND FILE AND PIPE IT INTO
# RUNMQSC - THIS WILL TURN THE TRIGGER BACK ON
# (TRIGGER WAS TURNED OFF BY MQ WHEN THIS SCRIPT WAS
# TRIGGERED)
##########################################################
commandFile='mqscCommand'
echo 'ALTER QLOCAL (' $queueName ') TRIGGER' 1>$commandFile
runmqsc $queueManagerName <$commandFile |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 18, 2006 3:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I am a little baffled as to the why...
- if the queue is serviced regularly like you have a listener or a trigger at first, there should be no expired message on it as it would disappear under the get.
- If the queue is not serviced regularly why would you send messages with expiry to it at all?
- If the servicing program is down and needs fixing wouldn't you know which queue it is and could schedule a browse every so often for the estimated down time passing the qname and qmgr as parms on the command line?
- It seems like a big effort for little return, but then I don't know how extensive you problem is and I might be completely off base.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Sep 18, 2006 3:24 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Scott,
The core app is an ESB. It is required to publish receipts for every Business Event message passed through the bus. Clients of the ESB would dequeue the event receipts if they were properly designed. The design of the ESB client applications is beyond the political scope of the ESB development team. These facts lead to a situation in which we are publishing messages to a queue for which there are 0 consumers. Here enters this ridiculous expiry scheme. The idea is to set MQMD.expiry and then to trigger a browse program on depth.
My remaining technical challenge for this approach is related to the need to KSH parse the MQTMC2 structure to glean both queueName and qmgrName for use as parameters to amqsbcg.
jd |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 18, 2006 3:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If they do not dequeue their receipts why subscribe them in the first place. Unsubscribe them and you won't have to deal with this problem at all.
Or allow only non durable subscriptions to the topic...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 19, 2006 1:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
FJ -
ivanachukapawn is not actually using Pub/Sub.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
