Jay Roy
asked on
spring ThreadPoolTaskExecutor
hi guys
I am using the spring frameworks ThreadPoolTaskExecutor
<bean id="myTaskExecutor" class="org.springframework .schedulin g.concurre nt.ThreadP oolTaskExe cutor">
<property name="corePoolSize" value="10" />
<property name="maxPoolSize" value="20" />
<property name="queueCapacity" value="25" />
</bean>
can anyone tell me how i should decide the size of corepoolzise, maxpoolsize.
what is queueCapacity and how do i decide the size of queueCapacity?
thanks
I am using the spring frameworks ThreadPoolTaskExecutor
<bean id="myTaskExecutor" class="org.springframework
<property name="corePoolSize" value="10" />
<property name="maxPoolSize" value="20" />
<property name="queueCapacity" value="25" />
</bean>
can anyone tell me how i should decide the size of corepoolzise, maxpoolsize.
what is queueCapacity and how do i decide the size of queueCapacity?
thanks
The Javadocs (http://download.oracle.com /javase/1. 5.0/docs/a pi/java/ut il/concurr ent/Thread PoolExecut or.html) seem pretty clear to me on this subject. Have another read of them and then if you still having issues understanding things, can you ask a more specific question?
This has a detailed description of the parameters you mentioned, although
they don't give direct recommendations, as these probably depend
on the specific situation and traffic in the particualr environment:
http://www.jdocs.com/utilconcur/2.2/edu/emory/mathcs/backport/java/util/concurrent/ThreadPoolExecutor.html
I guess, this paragraph has some connection to your questions:
Any BlockingQueue may be used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing:
If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing.
If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.
If a request cannot be queued, a new thread is created unless this would exceed maximumPoolSize, in which case, the task will be rejected.
ASKER
>>>can you ask a more specific question?
I have 100 queries which i am executing in the backend. I want to configure my corepoolsize,maxpoolsize and queuecapacity. what are the best numbers?
thx
I have 100 queries which i am executing in the backend. I want to configure my corepoolsize,maxpoolsize and queuecapacity. what are the best numbers?
thx
ASKER
also, i am using intel core i5 CPU @ 2Ghz with 3 gb RAM (my dev box)
When the app moves to production it will be @7ghz with 20gb ram.
When the app moves to production it will be @7ghz with 20gb ram.
What means 100 queries - would those be likely to be executed simultaneously?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
>>What means 100 queries - would those be likely to be executed simultaneously?
they are 100 sql update queries updating to a database table..They will be executed in parallel by the threadpool.
they are 100 sql update queries updating to a database table..They will be executed in parallel by the threadpool.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
If you are truly wanting them to run in parallel, then there would need to be at least 100 threads in the pool, ie. corePoolSize or maxPoolSize is set to 100 (or more). But you may find that trying to run all of them in parallel is actually slower, than running a smaller number in parallel and queuing the rest.
By the sounds of things, you probably wont need the all the features provided, so you could follow this rough guide. Set maxPoolSize to the maximum number of parallel queries you want to run (if you submit more than this number they will be queued). Set queueCapacity to a number greater than the number of queries you will ever try to submit at one time (if you try to submit more than this number the call to submit will fail and you would have to handle this error yourself). You can omit the queueCapacity setting and use Springs default which is the biggest queue possible (Integer.MAX_VALUE). Set corePoolSize the same as maxPoolSize if you don't want the threads to always be ready to go when tasks are submitted, or set it to a lower value if you want threads to be cleaned up when no queries are waiting to be run (this reduces resource usage but it means there could be a small delay when next you schedule queries, as the thread needs to be created again).
Another point to make, is that other than making sure the pool/queue is large enough to accept the max number of queries at any point in time, there is no RIGHT number to use. Any number will work (again subject to overall size) it just that they can be tuned to achieve the right performance/resource usage trade offs. It's all about TUNING the performance, not about whether it works or doesn't.
By the sounds of things, you probably wont need the all the features provided, so you could follow this rough guide. Set maxPoolSize to the maximum number of parallel queries you want to run (if you submit more than this number they will be queued). Set queueCapacity to a number greater than the number of queries you will ever try to submit at one time (if you try to submit more than this number the call to submit will fail and you would have to handle this error yourself). You can omit the queueCapacity setting and use Springs default which is the biggest queue possible (Integer.MAX_VALUE). Set corePoolSize the same as maxPoolSize if you don't want the threads to always be ready to go when tasks are submitted, or set it to a lower value if you want threads to be cleaned up when no queries are waiting to be run (this reduces resource usage but it means there could be a small delay when next you schedule queries, as the thread needs to be created again).
Another point to make, is that other than making sure the pool/queue is large enough to accept the max number of queries at any point in time, there is no RIGHT number to use. Any number will work (again subject to overall size) it just that they can be tuned to achieve the right performance/resource usage trade offs. It's all about TUNING the performance, not about whether it works or doesn't.