| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Broker timeout and Flow timeout |
« View previous topic :: View next topic » |
| Author |
Message
|
| sumit |
 Posted: Mon Apr 07, 2014 10:27 pm Post subject: Broker timeout and Flow timeout |
 |
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Hi All,
Configuration
OS - Linux
WMB - v8.0.0.3
Record and replay enabled.
Let's refer a small flow having design like-
HTTPInput node --> compute node --> SOAPRequest Node --> Compute node --> HTTPReply node
Timeout set at HTTPInput node - 58 secs
Timeout set at SOAPRequest node - 55 secs
Timeout set at application calling the flow - 60 secs
I understand (please verify), there are 2 kinds of timeout in such design.
1. Flow time out - Wherein SOAPRequest node took more than 55 secs to send a response. This timeout can be handled by connecting either SOAPRequest Failure termial or Catching it at HTTPInput node.
2. Broker time out -
With reference to what is given here in infocenter
| Quote: |
| Connections are made into the broker HTTP listener, which places requests on the SYSTEM.BROKER.WS.INPUT queue, from which the input nodes read the data. After the flow has reached a reply node, the reply data is placed on the SYSTEM.BROKER.WS.REPLY queue, where the data is read by the HTTP listener and sent back to the HTTP client. |
i.e. where the overall time taken by broker flow from getting a mesage from SYSTEM.BROKER.WS.INPUT and putting a reply on SYSTEM.BROKER.WS.REPLY took more than 60 secs (application time out). Reason could be because SYSTEM.BROKER.WS.INPUT is flooded with big messages.
My quries are,
1. can we handle these kinds of timeout scenarios (I understand 'Additional instance' is one thing)?
2. As the timeout is happening at broker level, flow level trace will not help me capture it. Is there any way to capture the error then?
3. Surprisingly, we didn't see time timeout info going to syslog. Has anyone else observed this?
_________________
Regards
Sumit |
|
| Back to top |
|
 |
| sumit |
| Posted: Mon Apr 07, 2014 10:53 pm Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
While searching here, I read this thread. It appears to me as similar problem, but OP didn't pursue the discussion further.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| sumit |
| Posted: Tue Apr 08, 2014 6:51 am Post subject: Re: Broker timeout and Flow timeout |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| sumit wrote: |
1. can we handle these kinds of timeout scenarios... |
Looks like we can use timeout terminal at HTTPInput node to catch these kinds of timeout. We are now working on it.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue Apr 08, 2014 6:54 am Post subject: Re: Broker timeout and Flow timeout |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
If I understand you correctly you have an application that makes an http request that is targeting your WMB message flow. Your application does not get a response within 60 seconds and times out.
| sumit wrote: |
| 1. can we handle these kinds of timeout scenarios |
That's the responsibility of your application. If you can put some code in it to handle the timeouts, then the answer is yes.
| sumit wrote: |
| 2. As the timeout is happening at broker level, flow level trace will not help me capture it. Is there any way to capture the error then? |
If you are not seeing anything in your user trace then the http request is probably not getting to your flow. If this is
| sumit wrote: |
| because SYSTEM.BROKER.WS.INPUT is flooded with big messages. |
(which I doubt) then there is no error to capture. Yout http message has not been processed yet.
| sumit wrote: |
| 3. Surprisingly, we didn't see time timeout info going to syslog. Has anyone else observed this? |
What would you expect to see in the syslog? It's your calling application that has timed out.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| sumit |
| Posted: Wed Apr 09, 2014 3:34 am Post subject: Re: Broker timeout and Flow timeout |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| fatherjack wrote: |
| sumit wrote: |
| 2. As the timeout is happening at broker level, flow level trace will not help me capture it. Is there any way to capture the error then? |
If you are not seeing anything in your user trace then the http request is probably not getting to your flow. |
The user trace says that flow has placed the message on the SYSTEM.BROKER.WS.REPLY queue. However, application says that the broker has timed out. I think it is because, the flow was able to process properly within the timeout interval defined in the flow input node. Yet the application level timeout has occurred. I am wondering if broker anyway keeps a check of timeout set at application level and sends a timeout response when application timeout value expires. Or is it completely handled at application level? 
| fatherjack wrote: |
| sumit wrote: |
| 3. Surprisingly, we didn't see time timeout info going to syslog. Has anyone else observed this? |
What would you expect to see in the syslog? It's your calling application that has timed out. |
The kind of example flow I gave in original query doesn't fit here. Please refer this flow--
| Code: |
| HTTPInput node --> compute node --> SOAPRequest Node1 --> Compute node --> SOAPRequest Node2 --> Compute node --> HTTPReply node |
Now, we have 2 soap request node calling 2 different webservices.
Timeout set at HTTPInput node - 58 secs
Timeout set at SOAPRequest node1 - 55 secs
Timeout set at SOAPRequest node2 - 55 secs
Timeout set at application calling the flow - 60 secs
(in an ideal design, sum of timeout defined at both the soapRequest node should be less that what is set at HTTPInput node.)
Now, let's say, a big message comes. SOAPRequest Node1 takes 18 secs to process the message. SOAPRequest Node2 takes 45 secs to process the message. As both soap nodes processed message within the set timeout, the message will reach final compute node. Final compute node will process and message and from HTTPReply node, the message will go to SYSTEM.BROKER.WS.REPLY queue. The timeout set at HTTPInput node is 58 secs but flow actually took 63 secs (18+45). Even in this case, user trace at flow level or syslog didn't capture an error. I was expecting that the flow will analyse the timeout before putting message on WS.REPLY queue and if it has timed out, it will throw an error for flow to catch. Looks like this is not how it actually works. 
_________________
Regards
Sumit |
|
| 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
|
|
|
|
