You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by sachin2008 <es...@gmail.com> on 2008/01/25 17:03:38 UTC
Problems with Executor
Hi , I have any issue with the Executorfactory and Executor .
I have simple JBI comonent . In this JBI component I am using the default
Executorfactory which i have coded as follows:
ComponentContextImpl context = (ComponentContextImpl) getContext();
ExecutorFactory factory = context.getContainer().getExecutorFactory();
executor = factory.createExecutor("component." +
context.getComponentName());
I am using the above created executor to run myown runnable object mfr as
follows:
executor.execute(mfr)
The above line calls mfr.start() method and spans a new thread of execution.
But, when I use the same line for 5th time, new thread is not being
spanned(start method is not being called).
While trying to find the reason for this , I found that servicemix creates
only 4 threads for every JBI component by default. So, the first 4 requests
are sucessful . when I request for 5th time , no thread is free in the pool
. So a new thread is not being created to handle my job.
Increasing the threadpool size solves my problem. But i want to know
whether it is possible to find
whether a new request for a thread is sucess or not .
Please tell me how to solve this problem with out increasing the pool size.
I am using servicmix 3.2 version.
--
View this message in context: http://www.nabble.com/Problems-with-Executor-tp15090865s12049p15090865.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Problems with Executor
Posted by sachin2008 <es...@gmail.com>.
Can U provide some logic for parallel processing inside a single component in
ESB.
bsnyder wrote:
>
> On Jan 25, 2008 9:03 AM, sachin2008 <es...@gmail.com> wrote:
>>
>> Hi , I have any issue with the Executorfactory and Executor .
>>
>> I have simple JBI comonent . In this JBI component I am using the default
>> Executorfactory which i have coded as follows:
>>
>> ComponentContextImpl context = (ComponentContextImpl) getContext();
>> ExecutorFactory factory = context.getContainer().getExecutorFactory();
>> executor = factory.createExecutor("component." +
>> context.getComponentName());
>>
>> I am using the above created executor to run myown runnable object mfr
>> as
>> follows:
>>
>> executor.execute(mfr)
>>
>> The above line calls mfr.start() method and spans a new thread of
>> execution.
>> But, when I use the same line for 5th time, new thread is not being
>> spanned(start method is not being called).
>>
>> While trying to find the reason for this , I found that servicemix
>> creates
>> only 4 threads for every JBI component by default. So, the first 4
>> requests
>> are sucessful . when I request for 5th time , no thread is free in the
>> pool
>> . So a new thread is not being created to handle my job.
>>
>>
>> Increasing the threadpool size solves my problem. But i want to know
>> whether it is possible to find
>> whether a new request for a thread is sucess or not .
>> Please tell me how to solve this problem with out increasing the pool
>> size.
>>
>> I am using servicmix 3.2 version.
>
> This behavior is a function of how the ThreadPoolExecutor from the
> JavaSE works. When the ThreadPoolExecutor is configured by the
> ServiceMix ExecutorFactoryImpl.createService() method, it does so
> using the corePoolSize and the maximumPoolSize properties from the
> conf/servicemix.properties file. The ThreadPoolExecutor then uses the
> values set using those properties to influence how the size of the
> thread pool is adjusted at runtime. Take a look at the paragraph below
> that I copied directly from the ThreadPoolExecutor's Javadoc. It
> describes how the corePoolSize and maximumPoolSize properties affect
> the behavior of the ThreadPoolExecutor's ability to allocate new
> threads:
>
> 'Core and maximum pool sizes
> A ThreadPoolExecutor will automatically adjust the pool size (see
> getPoolSize()) according to the bounds set by corePoolSize (see
> getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()).
> When a new task is submitted in method execute(java.lang.Runnable),
> and fewer than corePoolSize threads are running, a new thread is
> created to handle the request, even if other worker threads are idle.
> If there are more than corePoolSize but less than maximumPoolSize
> threads running, a new thread will be created only if the queue is
> full. By setting corePoolSize and maximumPoolSize the same, you create
> a fixed-size thread pool. By setting maximumPoolSize to an essentially
> unbounded value such as Integer.MAX_VALUE, you allow the pool to
> accommodate an arbitrary number of concurrent tasks. Most typically,
> core and maximum pool sizes are set only upon construction, but they
> may also be changed dynamically using setCorePoolSize(int) and
> setMaximumPoolSize(int).'
>
> (See
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
> for much more information on the ThreadPoolExecutor.)
>
> So to answer your question, the behavior you're seeing is the correct
> behavior of the ThreadPoolExecutor. As described in the paragraph
> above, the corePoolSize and maximumPoolSize can each be changed at
> runtime, but I don't think you should do this because will affect
> other ServiceMix components. The best thing that you can do is to
> configure an executor that is specifically for your custom JBI
> component via the ServiceMix thread pool configuration. See the
> following document for instructions on how to do this:
>
> http://servicemix.apache.org/thread-pools.html
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
>
> Blog: http://bruceblog.org/
>
>
--
View this message in context: http://www.nabble.com/Problems-with-Executor-tp15090865s12049p15199026.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Problems with Executor
Posted by Bruce Snyder <br...@gmail.com>.
On Jan 25, 2008 9:03 AM, sachin2008 <es...@gmail.com> wrote:
>
> Hi , I have any issue with the Executorfactory and Executor .
>
> I have simple JBI comonent . In this JBI component I am using the default
> Executorfactory which i have coded as follows:
>
> ComponentContextImpl context = (ComponentContextImpl) getContext();
> ExecutorFactory factory = context.getContainer().getExecutorFactory();
> executor = factory.createExecutor("component." +
> context.getComponentName());
>
> I am using the above created executor to run myown runnable object mfr as
> follows:
>
> executor.execute(mfr)
>
> The above line calls mfr.start() method and spans a new thread of execution.
> But, when I use the same line for 5th time, new thread is not being
> spanned(start method is not being called).
>
> While trying to find the reason for this , I found that servicemix creates
> only 4 threads for every JBI component by default. So, the first 4 requests
> are sucessful . when I request for 5th time , no thread is free in the pool
> . So a new thread is not being created to handle my job.
>
>
> Increasing the threadpool size solves my problem. But i want to know
> whether it is possible to find
> whether a new request for a thread is sucess or not .
> Please tell me how to solve this problem with out increasing the pool size.
>
> I am using servicmix 3.2 version.
This behavior is a function of how the ThreadPoolExecutor from the
JavaSE works. When the ThreadPoolExecutor is configured by the
ServiceMix ExecutorFactoryImpl.createService() method, it does so
using the corePoolSize and the maximumPoolSize properties from the
conf/servicemix.properties file. The ThreadPoolExecutor then uses the
values set using those properties to influence how the size of the
thread pool is adjusted at runtime. Take a look at the paragraph below
that I copied directly from the ThreadPoolExecutor's Javadoc. It
describes how the corePoolSize and maximumPoolSize properties affect
the behavior of the ThreadPoolExecutor's ability to allocate new
threads:
'Core and maximum pool sizes
A ThreadPoolExecutor will automatically adjust the pool size (see
getPoolSize()) according to the bounds set by corePoolSize (see
getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()).
When a new task is submitted in method execute(java.lang.Runnable),
and fewer than corePoolSize threads are running, a new thread is
created to handle the request, even if other worker threads are idle.
If there are more than corePoolSize but less than maximumPoolSize
threads running, a new thread will be created only if the queue is
full. By setting corePoolSize and maximumPoolSize the same, you create
a fixed-size thread pool. By setting maximumPoolSize to an essentially
unbounded value such as Integer.MAX_VALUE, you allow the pool to
accommodate an arbitrary number of concurrent tasks. Most typically,
core and maximum pool sizes are set only upon construction, but they
may also be changed dynamically using setCorePoolSize(int) and
setMaximumPoolSize(int).'
(See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
for much more information on the ThreadPoolExecutor.)
So to answer your question, the behavior you're seeing is the correct
behavior of the ThreadPoolExecutor. As described in the paragraph
above, the corePoolSize and maximumPoolSize can each be changed at
runtime, but I don't think you should do this because will affect
other ServiceMix components. The best thing that you can do is to
configure an executor that is specifically for your custom JBI
component via the ServiceMix thread pool configuration. See the
following document for instructions on how to do this:
http://servicemix.apache.org/thread-pools.html
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Blog: http://bruceblog.org/