| Author |
Message
|
| rajeshwmb3 |
 Posted: Sat Jan 19, 2013 9:09 am Post subject: UNABLE TO DEPLOY A MESSAGEFLOW AND DELETE AN EXECUTION GROUP |
 |
|
Newbie
Joined: 20 Nov 2012
Posts: 4
|
Hi,
I have a requirement to process multiple messages by using a collector node.
Initially the flow works good, I came across a wierd situation where the flow doesnt listen to the input queue.(This is happening when i process the flow and debug the flow and terminate the flow after any exception and then not able to set the the debug port, if i set the port java null pointer exception occurs).After that im not able to deploy the flow not able to delete the Execution Group. The flow is not even listening the input queue then onwards.
Im using Broker 7.0 and processing around 4 messages by using the COLLECTOR node.
please provide possible solutions. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sat Jan 19, 2013 6:35 pm Post subject: Re: UNABLE TO DEPLOY A MESSAGEFLOW AND DELETE AN EXECUTION G |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rajeshwmb3 wrote: |
| please provide possible solutions. |
Stop using the debugger. Other methods are available which can provide more information.
Or stop terminating the flow but allow it to run to completion.
Your issue probably stems from the fact a flow with a collector node spans 2 threads; one to the left of the node listening to the queue, one to the right processing the collection. Blowing one up with the debugger leaves the other orphaned.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jan 19, 2013 8:22 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The collector node is not for beginners. It takes a lot of trial and effort to make a properly working flow using this node.
My strike rate so far is 1 success and 1 failure.
From my experience, the Collector node works best when you can guarantee that there will be relevant data from all inputs before the collection times out.
My failure was with a data pattern that was totally variable. I never knew how many messages any one collection could have. The whole design relied upon the collection timing out and all the available data was then passed onto a back end flow. It ran for up to a week before I experienced the same problem as you. The only thing I could do was to kill the execution group process and then delete the flow with the collector node before it started processing messages.
I replaced this design with one using two DB tables and that has been running for two months now without any major issues.
My advice is that if you are sticking with the Collector node do as little as possible with the collection output thread and ensure that it has proper error handling. Don't try to use the debugger with the collector node. User trace is far more useful.
don't forget to properly test collection timeouts.
Take your time and analyse any changes you might make carefully and finally and most importantly try to break it with a proper test harness. Load it up with thousands of messages and keep it running for hours if not days until you are totally satisfied with its operation. Then and only then put it through the process that takes it into production.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| rajeshwmb3 |
| Posted: Sun Jan 20, 2013 2:16 am Post subject: |
|
|
Newbie
Joined: 20 Nov 2012
Posts: 4
|
Hi,
Thanks for the reply.
My requirement with the collector node arised because i need to call an existing service multiple times(more than twice and so on).
So, the no. of requests are not fixed.
I need to fire the multiple requests by calling the existing service based on the no. of requests and should seggregate the response from the collection once, also aggregate some of the responses based on the requirement.
What is the better option other than the collector node cause collector node really requires a lot of time and trial, still may not be productive in the end. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jan 20, 2013 5:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A collector node is used to assemble multiple inputs from multiple processes into a single record.
It is not designed to be used to aggregate responses from multiple requests.
Oddly enough, the Aggregate nodes are designed to aggregate multiple responses from multiple requests. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jan 20, 2013 5:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rajeshwmb3 wrote: |
My requirement with the collector node arised because i need to call an existing service multiple times(more than twice and so on).
So, the no. of requests are not fixed.
I need to fire the multiple requests by calling the existing service based on the no. of requests and should seggregate the response from the collection once, also aggregate some of the responses based on the requirement. |
I note you used the word aggregate there.
| rajeshwmb3 wrote: |
| What is the better option other than the collector node |
I think you answered your own question in your requirement.
| rajeshwmb3 wrote: |
| collector node really requires a lot of time and trial, still may not be productive in the end. |
It certainly needs to be set up correctly & code surrounding it needs to cover a lot of happy & unhappy use cases. It's perfectly productive if used to meet the kind of requirements it's designed to meet.
Which is why you find it less than productive; but mostly because you keep bashing threads with the debugger & expecting the system to automagically compensate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
