| Author |
Message
|
| junzi88 |
 Posted: Mon Nov 09, 2015 7:11 am Post subject: HTTPRequest Node Timeout Setting Does Not Work |
 |
|
Novice
Joined: 25 Sep 2013
Posts: 16
|
Hello,
Recently our HUB main flow stopped working for several time when back end mainframe was down. The symptom was HTTPRequest node calling backend services did not timeout and never came back. All instances seemed used up as we set 20 addtional instances. The HTTP listener were not accepting any new requests. The first node in main flow is HTTPInput node. However, the MQinput node was still accepting request and process the requests in same main flow. We opened PMR with IBM and sent those pstack and trance files to them. They just said it looked like threads waiting for backend responses.
Now to solve the issue, we set HTTPRequest node timeout from default value 240 to 60 seconds and hope Broker can release the instance in 60 seconds if no response from backend. After we tested this setting we found HTTPRequest node never timeout in 60 seoncds. Then I tried small flow HTTPInput=>HTTPRequest=>HTTPReply, all error and catch terminal go to another trace node then back to HTTPReply node. The timeout setting DOES work. However, if that trace node in error path has no link to HTTPReply node, HTTPRequest node does NOT timeout. Then I back to check our complicated main flow, it all have HTTPReply node in all path even after HTTPReply has othe nodes connected.
My question is that what scenario HTTPRequest node timeout setting stop working? How can I tackle the problem? Changing timeout setting would solve the instance release problem? Thank you! |
|
| Back to top |
|
 |
| gakd1987 |
| Posted: Thu Nov 12, 2015 1:47 pm Post subject: Did you set up the embedded port in the Execution group leve |
|
|
Apprentice
Joined: 20 Aug 2013
Posts: 26
|
Hi ,
The timeout to work the http port for the flow has to be setup at the execution group level instead of broker level. If the port used for your flow is broker level then the timeout will never reach the timeout terminal of the nodes rather the broker will send a default xml message. Change the port to use it in the execution group level and then your flow will certainly timeout. |
|
| Back to top |
|
|
| akil |
| Posted: Sat Nov 14, 2015 11:15 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
The message flow instance that invoked the http request will remain blocked till it receives a reply . The timeout in the http-request node is processed by a different thread, and ensures that a reply can be sent to the calling application. It does not release the instance...
_________________
Regards |
|
| Back to top |
|
|
| mgk |
| Posted: Sun Nov 15, 2015 12:59 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| The timeout in the http-request node is processed by a different thread, and ensures that a reply can be sent to the calling application. It does not release the instance |
This is not correct - I think you are mixing up HTTPRequest and HTTPInput nodes.
In this scenario, there are two different timeouts to consider. The first is the timout setting on the HTTPRequest node and the second is the timeout on the HTTPInput node.
If (or when) the HTTPRequest node timeout expires, then the instance processing the message will throw a SocketTimeOutException which will be sent to the failure terminal (if it is wired) or thrown back up the flow if the failure terminal is not wired. In either case, if the flow was started from an HTTPInput node then you will need to allow the exception to make it back to the HTTPInput node so it can send back the exception to the originating client or wire the caught exception (or failure terminal) to an HTTPReply node and send a reply yourself. If neither of these things happens then the originating client will be waiting for a response until the HTTPInput node timeout value is reached.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| akil |
| Posted: Sat Nov 21, 2015 7:30 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
Yes, I was mistaken. There isn't any separate Timeout terminal for the Request Nodes, they all go into the Failure terminal.
Can you tell me which are the error codes that are for Timeout , so that they can be differentiated from the other errors (unknown host etc ) ?
_________________
Regards |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 21, 2015 9:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| akil |
| Posted: Sat Nov 21, 2015 9:28 pm Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
My question was about the BIP error codes that will be part of the exception-list when the SocketTimeOut exception is raised and routed to the failure terminal.
How are HTTP status codes relevant?
_________________
Regards |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Nov 22, 2015 12:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| akil wrote: |
My question was about the BIP error codes that will be part of the exception-list when the SocketTimeOut exception is raised and routed to the failure terminal.
How are HTTP status codes relevant? |
Because you're supposed to use one to indicate timeout failure? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
