You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by muvvala <go...@gmail.com> on 2009/02/24 07:37:13 UTC
TIMED_WAITING of component thread pools
hi ,
I have created a new EIP component. I configured the thread pool for this
component as follows:
<bean class="org.apache.servicemix.executors.impl.ExecutorConfig">
<property name="corePoolSize" value="25"/>
<property name="maximumPoolSize" value="75"/>
<property name="queueSize" value="0"/>
</bean>
The problem is, when I sent a request to this component using send(), the
request is being processed sucessfully but in the Jconsole I could see the
following stack trace related to seda-flow.
Name: pool-flow.seda.servicemix-my-eip-thread-13
State: TIMED_WAITING on
edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node@551b97
Total blocked: 0 Total waited: 2
Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:432)
edu.emory.mathcs.backport.java.util.concurrent.TimeUnit.timedWait(TimeUnit.
java:301)
edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.attemp
t(SynchronousQueue.java:374)
edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.waitFo
rPut(SynchronousQueue.java:402)
edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue.poll(Synchr
onousQueue.java:566)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(T
hreadPoolExecutor.java:498)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.ru
n(ThreadPoolExecutor.java:689)
java.lang.Thread.run(Thread.java:595).
After some time(approx 1 min) all the threads are getting cleared. Is this a
default behaviour or did i missed anything.
--
View this message in context: http://www.nabble.com/TIMED_WAITING-of-component-thread-pools-tp22176645p22176645.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: TIMED_WAITING of component thread pools
Posted by Guillaume Nodet <gn...@gmail.com>.
This is the default behavior of the thread pool.
It will keep thread alive for some time, so that they can be reused.
This avoid the cost of creating a new thread each time. After the
timeout elapsed, the thread will be destroyed to avoid keeping too
much threads doing nothing in memory.
On Tue, Feb 24, 2009 at 07:37, muvvala <go...@gmail.com> wrote:
>
> hi ,
> I have created a new EIP component. I configured the thread pool for this
> component as follows:
>
> <bean class="org.apache.servicemix.executors.impl.ExecutorConfig">
> <property name="corePoolSize" value="25"/>
> <property name="maximumPoolSize" value="75"/>
> <property name="queueSize" value="0"/>
> </bean>
>
> The problem is, when I sent a request to this component using send(), the
> request is being processed sucessfully but in the Jconsole I could see the
> following stack trace related to seda-flow.
>
> Name: pool-flow.seda.servicemix-my-eip-thread-13
> State: TIMED_WAITING on
>
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node@551b97
> Total blocked: 0 Total waited: 2
>
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:432)
> edu.emory.mathcs.backport.java.util.concurrent.TimeUnit.timedWait(TimeUnit.
>
> java:301)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.attemp
>
> t(SynchronousQueue.java:374)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.waitFo
>
> rPut(SynchronousQueue.java:402)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue.poll(Synchr
>
> onousQueue.java:566)
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(T
>
> hreadPoolExecutor.java:498)
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.ru
>
> n(ThreadPoolExecutor.java:689)
> java.lang.Thread.run(Thread.java:595).
>
> After some time(approx 1 min) all the threads are getting cleared. Is this a
> default behaviour or did i missed anything.
>
> --
> View this message in context: http://www.nabble.com/TIMED_WAITING-of-component-thread-pools-tp22176645p22176645.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: TIMED_WAITING of component thread pools
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, iirc, the threads are not used only for requests, but also for responses.
Can you show the full configuration of the thread pool ? In which file
did you put the bean ?
On Tue, Feb 24, 2009 at 10:16, muvvala <go...@gmail.com> wrote:
>
> Thanks GNodet for you quick help.
>
> But, I am facing a small problem as follows:
>
> While load testing we got the following stack trace for some reason.
> In the stack trace, we observed RejectedExecutionPolicy is being used by the
> threadPool to process the threads. But, Rejcted execution comes only if the
> no of concurrent requestes exceeds maximum pool size. But we are shure that
> no of concurrent requests are less than maximum pool size.
>
> So i thought that, as the threads are being waited, those are not being used
> again. Is there any other reason for this behaviour(Rejected execution).
>
> Thanks in Advance.
>
>
> org.xml.sax.SAXParseException: The element type "BR" must be terminated by
> the matching end-tag "</BR>".
> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
> at
> org.apache.servicemix.soap.marshalers.SoapReader.readSoapUsingDom(SoapReader.java:95)
> at
> org.apache.servicemix.soap.marshalers.SoapReader.read(SoapReader.java:80)
> at
> org.apache.servicemix.soap.marshalers.SoapReader.read(SoapReader.java:73)
> at
> org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:162)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1497)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:407)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:880)
> at
> org.apache.servicemix.executors.impl.ExecutorImpl.execute(ExecutorImpl.java:42)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(SedaQueue.java:128)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(SedaFlow.java:191)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(SedaFlow.java:171)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(AbstractFlow.java:126)
> at
> org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(DefaultBroker.java:281)
> at
> org.apache.servicemix.jbi.container.JBIContainer.sendExchange(JBIContainer.java:793)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:381)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:456)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:428)
> at
> org.apache.servicemix.common.EndpointDeliveryChannel.sendSync(EndpointDeliveryChannel.java:88)
> at
> org.apache.servicemix.common.endpoints.SimpleEndpoint.sendSync(SimpleEndpoint.java:71)
> at
> com.dnb.eip.servicemix.patterns.MyStaticRoutingSlipEndPoint.processInOut(MyStaticRoutingSlipEndPoint.java:249)
> at
> org.apache.servicemix.common.endpoints.ProviderEndpoint.process(ProviderEndpoint.java:109)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
>
>
>
>
>
>
>
> muvvala wrote:
>>
>> hi ,
>> I have created a new EIP component. I configured the thread pool for this
>> component as follows:
>>
>> <bean class="org.apache.servicemix.executors.impl.ExecutorConfig">
>> <property name="corePoolSize" value="25"/>
>> <property name="maximumPoolSize" value="75"/>
>> <property name="queueSize" value="0"/>
>> </bean>
>>
>> The problem is, when I sent a request to this component using send(), the
>> request is being processed sucessfully but in the Jconsole I could see the
>> following stack trace related to seda-flow.
>>
>> Name: pool-flow.seda.servicemix-my-eip-thread-13
>> State: TIMED_WAITING on
>>
>> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node@551b97
>> Total blocked: 0 Total waited: 2
>>
>> Stack trace:
>> java.lang.Object.wait(Native Method)
>> java.lang.Object.wait(Object.java:432)
>> edu.emory.mathcs.backport.java.util.concurrent.TimeUnit.timedWait(TimeUnit.
>>
>> java:301)
>> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.attemp
>>
>> t(SynchronousQueue.java:374)
>> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.waitFo
>>
>> rPut(SynchronousQueue.java:402)
>> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue.poll(Synchr
>>
>> onousQueue.java:566)
>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(T
>>
>> hreadPoolExecutor.java:498)
>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.ru
>>
>> n(ThreadPoolExecutor.java:689)
>> java.lang.Thread.run(Thread.java:595).
>>
>> After some time(approx 1 min) all the threads are getting cleared. Is this
>> a default behaviour or did i missed anything.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/TIMED_WAITING-of-component-thread-pools-tp22176645p22178532.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: TIMED_WAITING of component thread pools
Posted by muvvala <go...@gmail.com>.
Thanks GNodet for you quick help.
But, I am facing a small problem as follows:
While load testing we got the following stack trace for some reason.
In the stack trace, we observed RejectedExecutionPolicy is being used by the
threadPool to process the threads. But, Rejcted execution comes only if the
no of concurrent requestes exceeds maximum pool size. But we are shure that
no of concurrent requests are less than maximum pool size.
So i thought that, as the threads are being waited, those are not being used
again. Is there any other reason for this behaviour(Rejected execution).
Thanks in Advance.
org.xml.sax.SAXParseException: The element type "BR" must be terminated by
the matching end-tag "</BR>".
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
at
org.apache.servicemix.soap.marshalers.SoapReader.readSoapUsingDom(SoapReader.java:95)
at
org.apache.servicemix.soap.marshalers.SoapReader.read(SoapReader.java:80)
at
org.apache.servicemix.soap.marshalers.SoapReader.read(SoapReader.java:73)
at
org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:162)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1497)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:407)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:880)
at
org.apache.servicemix.executors.impl.ExecutorImpl.execute(ExecutorImpl.java:42)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(SedaQueue.java:128)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(SedaFlow.java:191)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(SedaFlow.java:171)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(AbstractFlow.java:126)
at
org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(DefaultBroker.java:281)
at
org.apache.servicemix.jbi.container.JBIContainer.sendExchange(JBIContainer.java:793)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:381)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:456)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:428)
at
org.apache.servicemix.common.EndpointDeliveryChannel.sendSync(EndpointDeliveryChannel.java:88)
at
org.apache.servicemix.common.endpoints.SimpleEndpoint.sendSync(SimpleEndpoint.java:71)
at
com.dnb.eip.servicemix.patterns.MyStaticRoutingSlipEndPoint.processInOut(MyStaticRoutingSlipEndPoint.java:249)
at
org.apache.servicemix.common.endpoints.ProviderEndpoint.process(ProviderEndpoint.java:109)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
muvvala wrote:
>
> hi ,
> I have created a new EIP component. I configured the thread pool for this
> component as follows:
>
> <bean class="org.apache.servicemix.executors.impl.ExecutorConfig">
> <property name="corePoolSize" value="25"/>
> <property name="maximumPoolSize" value="75"/>
> <property name="queueSize" value="0"/>
> </bean>
>
> The problem is, when I sent a request to this component using send(), the
> request is being processed sucessfully but in the Jconsole I could see the
> following stack trace related to seda-flow.
>
> Name: pool-flow.seda.servicemix-my-eip-thread-13
> State: TIMED_WAITING on
>
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node@551b97
> Total blocked: 0 Total waited: 2
>
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:432)
> edu.emory.mathcs.backport.java.util.concurrent.TimeUnit.timedWait(TimeUnit.
>
> java:301)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.attemp
>
> t(SynchronousQueue.java:374)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue$Node.waitFo
>
> rPut(SynchronousQueue.java:402)
> edu.emory.mathcs.backport.java.util.concurrent.SynchronousQueue.poll(Synchr
>
> onousQueue.java:566)
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(T
>
> hreadPoolExecutor.java:498)
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.ru
>
> n(ThreadPoolExecutor.java:689)
> java.lang.Thread.run(Thread.java:595).
>
> After some time(approx 1 min) all the threads are getting cleared. Is this
> a default behaviour or did i missed anything.
>
>
--
View this message in context: http://www.nabble.com/TIMED_WAITING-of-component-thread-pools-tp22176645p22178532.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.