Link to home
Create AccountLog in
Avatar of Jay Roy
Jay RoyFlag for United States of America

asked on

spring ThreadPoolTaskExecutor

hi guys
I am using the spring frameworks ThreadPoolTaskExecutor
<bean id="myTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
        <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
Avatar of mccarl
mccarl
Flag of Australia image

The Javadocs (http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.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.
Avatar of Jay Roy

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
Avatar of Jay Roy

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.
What means 100 queries - would those be likely to be executed simultaneously?
ASKER CERTIFIED SOLUTION
Avatar of mccarl
mccarl
Flag of Australia image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Avatar of Jay Roy

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.
SOLUTION
Link to home
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.