You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by sic <si...@naver.com> on 2010/02/11 10:26:35 UTC
thread pool of servicemix-http component
I'm using servicemix-3.2
And I have set webservice work by using servicemix-http component.
That is, clients request our servicemix-http consumer, then the consumer
passes the request to the servicemix-http provider in order to call the
external webapp server as it is.
Additinally we still use the old style's endpoints like the following as we
didn't apply new http endpoints :
<http:endpoint service="ws:A"
endpoint="endpoint1"
targetService="ws:A"
targetEndpoint="endpoint2"
role="consumer"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
soap="true"
soapVersion="1.1"
locationURI= ...
wsdlResource= ...
</http:endpoint>
<http:endpoint service="ws:A"
endpoint="endpoint2"
role="provider"
soap="true"
soapVersion="1.1">
locationURI= ...
wsdlResource= ...
</http:endpoint>
BTW, I have a question about the thread pool of servicemix-http. In SMX, it
can pool entire threads at each flow and component by the configuration such
as corePoolSize, maxinumPoolSize ...
In case of HTTP component, it can also be controlled by jettyThreadPoolSize
in configuration of component.properties.
Then what is the valid configuration of servicemix-http? As mentioned above,
I think, it seems that 3 configurations are related to the threads of
servicemix-http component :
1. corePoolSize, maxinumPoolSize, queueSize in sm:executorFactory of
flow.seda.servicemix-http(we are using seda flow)
2. corePoolSize, maxinumPoolSize, queueSize in sm:executorFactory of
component.servicemix-http
3. servicemix-http.jettyThreadPoolSize in component.properties
I guess that component.servicemix-http doesn't affect the thread pool as a
result of debugging.
And the problem with our work is that a number of requests from clients are
executed by the http-components in slowdown state of the external webapp
server.
Does anyone help to explain the relation among these configuration?
regards,
sic
--
View this message in context: http://old.nabble.com/thread-pool-of-servicemix-http-component-tp27544234p27544234.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: thread pool of servicemix-http component
Posted by Gert Vanthienen <ge...@gmail.com>.
sic,
The jetty thread pool settings will configure the amount of threads
that are available for handling incoming HTTP requests. If you
enlarge this thread pool, the component will be capable of accepting
more requests simultaneously. In ServiceMix, the HTTP request usually
results in a MessageExchange being sent to the ESB. That's where the
flow thread pool comes into play, it the number of thread available
for conveying the exchange to the target components so that it can get
handled.
In this scenario, you probably want to enlarge both thread pools
simultaneously -- it won't help if you increase the number of threads
available for accepting requests if you don't have a matching thread
pool to actually handle the exchanges. For the flow executor pool,
there's also the the queue size parameter to help tune things -- it
defines the number of pending work items in the queue before an
additional thread gets started to handle the workload. In case of
sudden increases/decreases in the load, that parameter will avoid
creating new threads and destroying them again for just handling a few
requests beyond the current thread pool size.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On 11 February 2010 10:26, sic <si...@naver.com> wrote:
>
> I'm using servicemix-3.2
>
> And I have set webservice work by using servicemix-http component.
>
> That is, clients request our servicemix-http consumer, then the consumer
> passes the request to the servicemix-http provider in order to call the
> external webapp server as it is.
> Additinally we still use the old style's endpoints like the following as we
> didn't apply new http endpoints :
>
> <http:endpoint service="ws:A"
> endpoint="endpoint1"
> targetService="ws:A"
> targetEndpoint="endpoint2"
> role="consumer"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> soap="true"
> soapVersion="1.1"
> locationURI= ...
> wsdlResource= ...
> </http:endpoint>
>
> <http:endpoint service="ws:A"
> endpoint="endpoint2"
> role="provider"
> soap="true"
> soapVersion="1.1">
> locationURI= ...
> wsdlResource= ...
> </http:endpoint>
>
> BTW, I have a question about the thread pool of servicemix-http. In SMX, it
> can pool entire threads at each flow and component by the configuration such
> as corePoolSize, maxinumPoolSize ...
> In case of HTTP component, it can also be controlled by jettyThreadPoolSize
> in configuration of component.properties.
> Then what is the valid configuration of servicemix-http? As mentioned above,
> I think, it seems that 3 configurations are related to the threads of
> servicemix-http component :
> 1. corePoolSize, maxinumPoolSize, queueSize in sm:executorFactory of
> flow.seda.servicemix-http(we are using seda flow)
> 2. corePoolSize, maxinumPoolSize, queueSize in sm:executorFactory of
> component.servicemix-http
> 3. servicemix-http.jettyThreadPoolSize in component.properties
>
> I guess that component.servicemix-http doesn't affect the thread pool as a
> result of debugging.
> And the problem with our work is that a number of requests from clients are
> executed by the http-components in slowdown state of the external webapp
> server.
>
> Does anyone help to explain the relation among these configuration?
>
> regards,
>
> sic
>
> --
> View this message in context: http://old.nabble.com/thread-pool-of-servicemix-http-component-tp27544234p27544234.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>