| Author |
Message
|
| w |
 Posted: Thu Aug 04, 2011 10:10 pm Post subject: How threads work in Broker? |
 |
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
Hi,
I need to know how threads work in WMB.
I have created a bar file with additional instances set to zero.That means when it gets deployed only one thread at a time will be running.Now suppose two requests come to it concurrently.What will happen now?Will one of the request wait till the other is fully processed ?
Plz help . Thanks in advance.  |
|
| Back to top |
|
 |
| j.f.sorge |
| Posted: Thu Aug 04, 2011 11:25 pm Post subject: |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
I think it depends on the kind of input node you use.
_________________
IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| w |
| Posted: Fri Aug 05, 2011 12:37 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| I am using SOAP Input nodes. |
|
| Back to top |
|
|
| j.f.sorge |
| Posted: Fri Aug 05, 2011 2:54 am Post subject: |
|
|
Master
Joined: 27 Feb 2008
Posts: 218
|
|
| Back to top |
|
|
| w |
| Posted: Fri Aug 05, 2011 3:24 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| The documentation does not really help.Actually I have the following query.I have exposed a web service which internally calls another web service.This service is deployed with additional instances equal to 0.Now is it possible that if a no. of concurrent requests come to WMB then the processing of one of the requests starts while processing of another is still not finished. Actually I need to ensure that there are no simultaneous calls to the external system even if the external system takes a lot of time. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 05, 2011 4:24 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Correct. Or, Filipino-style: korek. If additional instances is zero, the concurrent calls will be handled sequentially. If you want concurrent calls to be handled in parallel, then you need more than zero additional instances. If the latency on your downstream is one second, and you have two concurrent calls, the second call will have an effective latency of two seconds, because it has to wait for the first request to complete.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| w |
| Posted: Fri Aug 05, 2011 4:47 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
Thanks lancelotlinc that answers my question.  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 05, 2011 4:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
To be more precise, the additional instances will control the number of threads within message broker that run.
This is not the same thing as the number of threads that run in the http listener that is being used by Broker to receive the soap input calls - the EG level listener. That number of threads is controlled by something else.
So it is possible to submit more than one request simultaneously to a flow that has zero additional instances and they will be accepted and processed by the listener simultaneously - but the flow itself will not process them other than sequentially. |
|
| Back to top |
|
|
| ghoshly |
| Posted: Fri Aug 05, 2011 11:28 am Post subject: number of threads for the http listener |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
Hi Jeff/ Lance/all,
How to configure the thread count of the http listener for the broker to accept request? Is it max 255 count? Is there a way or configurable service to modify that based on business need?
Thanks a lot. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 05, 2011 11:41 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| MikeH |
| Posted: Fri Apr 20, 2012 5:34 am Post subject: Swamping the number of threads on HTTP/SOAP input |
|
|
Newbie
Joined: 20 Apr 2012
Posts: 3
|
I have a similar requirement and can use a little more guidance than the help provides.
This is a stress test and we are running our flows to several times there anticipated volumes. Our goal is to gather the indicators of that stress and therefore plan and monitor accordingly.
We built a flow that passes SOAP using an HTTP Node and we are able to see the work building up on the SYSTEM.BROKER.WS.INPUT queue so this one we have covered.
We also built a flow that uses a SOAP node and we are not able to see the work building on any specific queues. What can we watch to see the broker falling behind ?
Thanks,
Mike |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Apr 20, 2012 5:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
With real data that needs to be parsed, you may find that SOAPInput node is the more efficient method than SOAP over HTTPInput. With dummy data that is not parsed, the opposite is true.
To measure internal performance, use a Singleton through a Java Compute node to collect statistics in JMX MBeans. Track latency through the MBeans. When Broker starts to fall behind, the latency will expand.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| optimist |
| Posted: Fri Apr 20, 2012 10:23 am Post subject: Soap nodes cannot use broker-wide listener... |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
Your question: "We also built a flow that uses a SOAP node and we are not able to see the work building on any specific queues. What can we watch to see the broker falling behind ?"
can be explained by the IBM InfoCenter documentation that reads:
"SOAP nodes always use the listener that is embedded in the execution group, and only this listener; you cannot configure them to use the broker-wide listener".
The Soap requests go thru' the embedded listener and there are no queues in-between as in the case of the broker-wide listener.
More details here:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ac56650_.htm |
|
| Back to top |
|
|
| MikeH |
| Posted: Fri Apr 20, 2012 2:13 pm Post subject: More on SOAP input |
|
|
Newbie
Joined: 20 Apr 2012
Posts: 3
|
So the solution we are building has multiple execution groups each with its own listener, and multiple flow instances (100 per EG). The objective is to provide a high volume WS/SOAP service at very high response rates (in milliseconds).
So during our performance/stress tests we are going to 3x expected volumes and as expected we see some resource starvation issues. We want to be able to detect that the SOAP input has more requests than the broker can service.
To add to the complexity these requests timeout really quickly and therefore the calling application may go away before the request even gets an instance to process it. To detect this we log the Properties.CreateTime which seams to contain first contact date/time and we compare to current date/time in the first compute but other ideas are welcome.
Mike |
|
| Back to top |
|
|
| MikeH |
| Posted: Sat Apr 21, 2012 8:43 am Post subject: Swamping the number of threads on SOAP input (cont...) |
|
|
Newbie
Joined: 20 Apr 2012
Posts: 3
|
I made a test jig and worked it to get the answer.
The SOAP input node manages the requests and the ones that time out may never get to the message flow instance. This is great for efficiency but you simply never know if the work came and went before you started processing.
So the real answer is ...
You can't find out if the broker is falling behind on a SOAP input node.
Well, you can but then you end up staging work on a queue and handling the timeouts yourself. Which isn't really the "as fast as possible" approach that I need.
Mike |
|
| Back to top |
|
|
|
|
