| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Soap Nodes, Additional Instances and timeouts |
« View previous topic :: View next topic » |
| Author |
Message
|
| ruimadaleno |
 Posted: Fri Oct 31, 2014 6:39 am Post subject: Soap Nodes, Additional Instances and timeouts |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi all,
i'm trying to understand the relations between soapnodes, additional instances and timeout processing in WBM.
I've searched documentation and done some searching in this forum but my mind is not clear 
first of all some info about my environment:
WMB 8.0.0.4 running on windows 2008 Server R2 Standard
Single Execution group
several message flows deployed. Each message flow uses soapinput/soapreply nodes (typical web services)
using embedded http listener
now the scenario:
message flow deployed in execution group described above.
Additional instances set to zero (this means there is only one thread to process incoming request)
Message A arrives to soapinput node (request 1), processing of the message starts.
meanwhile, message B arrives at soapinput node (request 2).
Suppose that message flow is still processing request 1. What happens to request 2 ?
The request is "kept" in a "request queue" for an known amount of time , waiting for an available worker thread to process it.
What happens if this time "known amount of time" is used ? a timeout happens ? the request 2 is discarded ? a fault message is sent to client ? what are the events i should expect to be raised in soapinput node ( transaction start + timeout ?)
how much is this "known amount of time" ? 30 seconds ? is it configurable somewhere in WMB ?
This request queue is implemented in MQ ? another internal implementation ? how are the requests handled (algorithm) in this queue ? fifo ? round robin ?
is this queue limited ? how many requests does it handle ? is it configurable ?
so many questions 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Oct 31, 2014 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Is this connected to the behaviour you described here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 31, 2014 7:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The capacity is 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.
These values can be changed in the usual way.
http://www-01.ibm.com/support/docview.wss?uid=swg21504029
_________________
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 |
|
|
| ruimadaleno |
| Posted: Fri Oct 31, 2014 7:54 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| Vitor wrote: |
| Is this connected to the behaviour you described here? |
Hi Vitor,
yes, it's related. I'd like to understand how WMB handles high volumes of requests to message flows that implement web services using soap nodes.
I've decided to open a new thread to separate the waters.
Thank you for your help.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 31, 2014 8:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The soap listener doesn't use MQ queues. The bipHTTPListener does.
Messages can time out either in the SOAP listener or in the BIPHTTPListener or on the internal queues. This will not cause any event to occur at any broker nodes. No terminals will be called, no monitoring events will be generated, etc.
Timeout terminals are only called once the Input node in question is invoked.
So if you have maxThreads set to 1, and you send in 1000 requests all at once, some reasonable number of those requests are going to timeout, and the only thing that will get notified is the client. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Oct 31, 2014 8:08 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| zpat wrote: |
The capacity is 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.
These values can be changed in the usual way.
http://www-01.ibm.com/support/docview.wss?uid=swg21504029 |
Hi zpat, thank you for your response.
what about the time that requests can "live" in this queue before timeout ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| akil |
| Posted: Wed Nov 05, 2014 3:20 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
A few observations from my tests using SOAP UI,
maxThreads=2,
acceptCount=2,
additionalInstances=0,
the service has one operation called timeout, which sleeps for the duration passed to it, I used 3 seconds for the tests.
The SOAP Input is configured for a 5 second timeout.
The observations are from the debug trace file of the execution group (haven't yet traced the HTTP listener)
I sent 10 requests, thinking that requests starting the 5th one will get rejected, but no request was rejected, they just waited but all got serviced
In the trace file, I saw all the 10 requests, so no request was rejected by the server
The requests were serviced in a random order, not in FIFO, of the 10 requests I sent, request number 3 took 57 seconds and request number 4 timed out at SOAP UI (which is 120 seconds), while request 5 - 10 came back earlier
The SOAP node never timed out, which is expected as the flow never took more than 3 seconds to complete (which is less than configured 5 seconds), implying that the timeout at the SOAP Node starts after the request has been received by the message processing thread (and not the time since the request was received at the http listener)
the login in the trace file seems to be done after the message is picked up for processing, and not when it arrives, that's the reason you see varied timestamps, while I sent the within 5 seconds. I guess i've to augment this with the http trace
| Code: |
2014-11-05 16:32:00.428959 12737 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:01.326622 12738 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:04.144473 12737 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:08.826471 12738 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:14.287792 12738 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:23.027154 12738 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:24.473416 12737 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:32:56.449948 12738 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:33:01.452918 12737 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
2014-11-05 16:33:04.467098 12737 UserTrace BIP3630I: The broker has received an HTTP message on port '7800' with URL path '/SadService/SadService'.
|
[/list]
_________________
Regards |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Wed Nov 05, 2014 8:31 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Nice work akil 
my theory:
your 10 requests were processed because none of it stayed "on hold"/queue long enough to expire.
what we are missing here ? The interval of time requests can wait "on hold"/queue ! i suspect this "magic" value is 30 seconds (found nothing in documentation to validate this)
Can you try the following scenario:
maxthreads = 2
acceptcount = 2
additional instances = 0
sad service soap input node timeout = 120 seconds
try to send 10 requests, with one second interval between each request. Each one of this requests will execute the timeout operation from sadservice with 45 seconds.
so, my theory:
Request 1 - This request is immediately served by sadservice (one thread available), this thread will be processing (sleeping) for 45 seconds.
Request 2 - when the request arrives, there is no sadservice thread to process, so it will be held by an http listener thread (because we have maxthreads = 2)
Request 3 - when the request arrives, there is no sadservice thread to process, so it will be held by an http listener thread (because we have maxthreads = 2)
Request 4 - When request arrives , there is no sadservice thread to process. because we have maxthreads = 2 and request 2 and request 3 are using this 2 threads , request 4 will be put on queue (because we have acceptcount = 2)
Request 5 - When request arrives , there is no sadservice thread to process. because we have maxthreads = 2 and request 2 and request 3 are using this 2 threads , request 5 will be put on queue (because we have acceptcount = 2)
Request 6 - This is where things get interesting  there is no sadservice thread to process. There is no http listener threads (because maxthreads=2 and request2 and request3 are holding this threads). Because we have accept count = 2, there is no space in queue to hold request 6.... so .. what happens ?
request is discarded , soap fault message is sent to client ?
_________________
Best regards
Rui Madaleno |
|
| 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
|
|
|
|
