| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Purge Queue - Move Queue from WMB message flow |
« View previous topic :: View next topic » |
| Author |
Message
|
| CuriCAT |
 Posted: Wed Apr 27, 2011 2:35 pm Post subject: Purge Queue - Move Queue from WMB message flow |
 |
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
Can you please clarify my doubts, I appriciate your help:
I have 2 design requirements, that needs to be perform in WMB message flow upon some conditions:
1) I want to purge queue on a certain event
2) I want to move messages from one Queue to another Queue on certain Event.
Is there a java program I can embed into message flow to connect to a queue and purge the messages or move the messages. Is there any built-in features available with message broker code.
Environment :
AIX Version 5.3
WMB V 6.1
MQ V7
Thanks for your valuable comments. |
|
| Back to top |
|
 |
| jlaisbett |
| Posted: Wed Apr 27, 2011 3:34 pm Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009
Posts: 39
|
I don't think you'd need to use Java for this and using Java for MQ related tasks in broker should probably be reserved as an absolute last resort.
1) You could probably do this using an MQGet node with basic looping from a compute node until there are no messages left
2) This should be easy enough using MQInput/MQGet nodes paired with MQOutput nodes
I strongly encourage you to look at the available nodes, especially the MQ ones to determine which ones you need:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac04550_.htm |
|
| Back to top |
|
|
| CuriCAT |
| Posted: Wed Apr 27, 2011 3:45 pm Post subject: |
|
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
| Thanks for your advice Jlaisbett, I have developed message flow with MQGET node for PURGE and MOVE queue. It worked for few messages, but didn't work for large number of messages. if it is 40 messages then it purges , if its 200 messages then i see the queue depth is increasing by duplicate messages. |
|
| Back to top |
|
|
| jlaisbett |
| Posted: Wed Apr 27, 2011 4:15 pm Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009
Posts: 39
|
I can't think of any reason why the queue depth would actually increase for large numbers of messages, sounds like a different problem.
Without knowing more more about the solution I can't really help with that one. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 27, 2011 4:27 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you're dealing with processing a large number of messages on a queue, in different ways, I might take the approach of using Broker to tell Broker to start or stop a message flow, rather than using Broker to read or discard a large number of messages in the same transaction (likely this is the actual issue with your MQGet node, that you're using the same transaction).
Well, the other possibility is that you've done entirely the wrong thing with your MQGet node and used node connections to build a loop. That tends to fail rather drastically at about 40 times around. |
|
| Back to top |
|
|
| Gerd-in-ZA |
| Posted: Thu Apr 28, 2011 10:48 am Post subject: |
|
|
Novice
Joined: 13 Sep 2006
Posts: 14
Location: Johannesburg, South Africa
|
I am also not convinced that you need Java for this - except if you want to design your solution around starting and stopping message flows from within a flow via the CMP API.
To purge a queue you need a flow that consists of an MQInput node and nothing else - many students stumble across this during their first course exercises. If you want to be relatively fast about it you can try to define many parallel instances of this flow. You can also configure it to commit only after every 10 to 20 executions or so, but watch your MQ's log size!
To move all messages to a different queue takes an MQInput node and an MQOutput node plus possibly some mechanism to change the destination queue name without having to redeploy the flow, although you could do all of that in the CMP API as well. If you are fond of this sort of thing you can really "go to town" on this solution design. Again, parallel execution and commits only every so often are options, and again, watch your MQ log sizes. You must also watch out if you want the message sequence to be preserved - in that case parallel execution of additional instances is a no-no.
There are two things potentially wrong with the loop of MQGet nodes as proposed earlier in this thread:
One is that while you do all this work in the same flow instance you are doing all your work in the same unit of work (in MB a UoW only ends once the flow instance ends) and that means you are potentially using up a lot of MQ log space. No problem if you configure your logs big enough, but you probably didn't. You could also configure your flows to be non-transactional and that problem goes away.
But the second problem will remain: As you loop through your flow, invoking the MQGet node many times, there is a message assembly that gets copied and passed on for each iteration. So your flow is going to be rather memory hungry. Again, as an experienced MB administrator you can probably configure your broker to accommodate that, but I doubt that it will be called "best practice", all told.
The separate flows that I sketched out above will run through many iterations and as such won't use unreasonable amounts of resources - and I gave you hints how to tune them a bit.
Speaking about "best practice" - just for the purposes of discussing that here I would put some doubt on whether it is a clever thing to collect a ton of messages in one queue and then to shovel them all into another queue or - even better - into the "Great Bit Bucket In The Sky".
_________________
-- Gerd -- |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
