| Author |
Message
|
| gakd1987 |
 Posted: Wed Dec 23, 2015 7:35 am Post subject: Can we set the httptimeout for a execution group level? |
 |
|
Apprentice
Joined: 20 Aug 2013
Posts: 26
|
Is there a way to set the httptimeout property at the execution group level instead of individual httpinput node or hhtprequest node level ?
Also is there a command in mqsireportproperties to figure out and also mqsichangeproperties to change the timeout property ? |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Dec 23, 2015 7:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If you use the embedded (EG level) listener for http nodes (which is an option), then you can set properties of that listener.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| gakd1987 |
| Posted: Wed Dec 23, 2015 11:43 am Post subject: Yes I have used EG level listener |
|
|
Apprentice
Joined: 20 Aug 2013
Posts: 26
|
| How can i set the properties of timeout at the EG level instead of the httpinput node level ? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 24, 2015 12:08 am Post subject: Re: Yes I have used EG level listener |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| gakd1987 wrote: |
| How can i set the properties of timeout at the EG level instead of the httpinput node level ? |
how about looking at the 'mqsichangeproperties' command as it is described in the product documentation.
_________________
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 |
|
|
| zpat |
| Posted: Thu Dec 24, 2015 1:44 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't see the logic in setting a timeout inside an input node. Surely it is whatever is invoking the flow that has a timeout value?
If you are making http requests inside the flow then you should be able to promote any property of the node to flow level to make it easier to override.
Having said that there are various factors that influence how the http listener handles incoming requests, for example if no flow instance is available to process the incoming connection - how long does it wait for a flow instance to become available before rejecting the connection?
How many pending connections can it allow before it has to reject incoming connections, all these sort of factors can come into play. Increasing the internal queue can be a good thing, but it can also mask a problem and prevent your load-balancer from seeing it (and routing around it).
These are maxThreads + acceptCount. Each incoming request consumes a tomcat thread to process and maxThreads controls the size of the Tomcat thread pool. The accept count parameter controls how many connection requests are accepted and queued when all tomcat threads are in use.
One has to ask what is the underlying reason for your question?
Of course the best solution is to avoid all the mess of synchronous protocols and use MQ for all application integration. You know it makes sense.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
