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 <[email protected]> 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. > >
