| Author |
Message
|
| RaviKrG |
 Posted: Mon Jan 17, 2011 4:58 am Post subject: Message Time Out - Message processing slow |
 |
|
Master
Joined: 07 Sep 2008
Posts: 240
|
Hi, The deployed flow take lot of time to process a message. when we took a browse we see a very interesting thing.
2011-01-17 15:21:47.608040 43 UserTrace BIP4007I: Message propagated to 'out' terminal of node '***********.LoadParameters.PreLoadParameters'.
2011-01-17 15:25:33.063912 43 UserTrace BIP2537I: Node '**********.LoadParameters.LoadParameters': Executing statement ''DECLARE Parameters ROW;'' at ('.Parameters', '1.1').
Any reasons this couls happen. Finally the message gets process but because of this it gives an error to front end as time out.During this time I see no muck cpu utilization. |
|
| Back to top |
|
 |
| fatherjack |
| Posted: Mon Jan 17, 2011 5:07 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
How big are the messages ?
What type of messages ?
What are the nodes in your flow ?
What parsing options are you using ?
Any validation ?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| RaviKrG |
| Posted: Mon Jan 17, 2011 7:09 am Post subject: |
|
|
Master
Joined: 07 Sep 2008
Posts: 240
|
How big are the messages ? not more than 5K
What type of messages ? Siebal
What are the nodes in your flow ? its normal (mqout,subflow,mqreply,trace,compute,routetolabel,flow order, databse.
What parsing options are you using ? xmlnsc
Any validation ?validation means at esql label |
|
| Back to top |
|
|
| fatherjack |
| Posted: Mon Jan 17, 2011 7:20 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| RaviKrG wrote: |
| How big are the messages ? not more than 5K |
Good
| RaviKrG wrote: |
| What type of messages ? Siebal |
And what type are these? XML ? TDS? BLOB? Etc?
| RaviKrG wrote: |
What are the nodes in your flow ? its normal (mqout,subflow,mqreply,trace,compute,routetolabel,flow order, databse.
|
I meant the ones relating to the snippet of the trace you posted.
| RaviKrG wrote: |
| What parsing options are you using ? xmlnsc |
Parsing options, as defined for the nodes. Not just the Parser.
| RaviKrG wrote: |
| Any validation ?validation means at esql label |
As defined for the nodes.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| RaviKrG |
| Posted: Mon Jan 17, 2011 7:41 am Post subject: |
|
|
Master
Joined: 07 Sep 2008
Posts: 240
|
And what type are these? XML ? TDS? BLOB? Etc? --> XML
I meant the ones relating to the snippet of the trace you posted. (SubFlow ----> Compute Node) and the subflow (betwen two compute nodes) this is not the full flow 
Parsing options - default (unchecked)
Validations - none |
|
| Back to top |
|
|
| fatherjack |
| Posted: Mon Jan 17, 2011 8:36 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
So what you're saying is that from the time the message is propagated to the out terminal of one compute node to the time the first statement gets executed in the compute node that immediately follows this one, it takes about 4 minutes.
Do all messages take about this long?
And there's no cpu or memory issues on the box?
And what about the time taken between other adjacent nodes in the flow?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 17, 2011 8:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| And there aren't any other message flows running in the same EG? |
|
| Back to top |
|
|
| RaviKrG |
| Posted: Mon Jan 17, 2011 9:05 am Post subject: |
|
|
Master
Joined: 07 Sep 2008
Posts: 240
|
Yes there are many flows deployed under that EG. the cpu and memory utilization looks good when this is happening. there is one flow which takes around 15 % of cpu, but thats a different one. and yes not all the messages happen to be same but yes 95 % takes the same. .. and
all the other staments are normal in time execution.. only the time between the two statements which I have given is more.
also when they are trying to connect to other machines those are all fine but they are all different applications. and this applications which is creating all the issue is on solaris. mb 6.1. adn rest are aix machines. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 17, 2011 9:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Isolate the flow to it's own EG.
See if you still have the same performance issue.
If you DON'T, then it's *not* the flow.
Otherwise, there's not nearly enough information that you have given us to provide any more assistance. We've no idea, for example, if the node BEFORE the compute node is perhaps a SOAPRequest node that is taking forever to return back from the request.... or etc. |
|
| Back to top |
|
|
| RaviKrG |
| Posted: Mon Jan 17, 2011 9:18 am Post subject: |
|
|
Master
Joined: 07 Sep 2008
Posts: 240
|
Thanks jeff.
believe or not the time difference between the two statements are between two compute nodes.
and yes I am thinking of isolating the flow and then testing it out. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Mon Jan 17, 2011 1:04 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| RaviKrG wrote: |
Thanks jeff.
believe or not the time difference between the two statements are between two compute nodes.
and yes I am thinking of isolating the flow and then testing it out. |
So what's the first compute node doing?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| RaviKrG |
| Posted: Thu Jan 20, 2011 12:36 am Post subject: |
|
|
Master
Joined: 07 Sep 2008
Posts: 240
|
Thanks all for the help. At present the issue stands resolve. Have not done anything. Just deployed the only flow which was having issues to other EG and tested and all was fine. Also deployed the flow on other server and checked and all was fine. later again we tested with the old flow and all looked good. not sure why it was creatig this issue before. but still we aretrying to test this again and again. will update you again
thanks |
|
| Back to top |
|
|
|
|
