wood burning stoves*
The moose likes Threads and Synchronization and the fly likes use of FutureTask Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "use of FutureTask " Watch "use of FutureTask " New topic
Author

use of FutureTask

partha naveen
Ranch Hand

Joined: Jul 17, 2008
Posts: 32
Hi,

Would like to know if the use of FutureTask has led to any known issues like performance bottleneck, sudden thread kills etc? I am proposing this for an application that makes a direct API call which internally makes a httpclient request over the network. Using the same thread to do this in Tomcat is often creating problems for Tomcat and the server is going down. To avoid that this API call is now planned to be routed via a futuretask worker (Callable) thread with a designated TimeOut. Can there be any issues with this since the user base is really very large?


Thanks and Regards
Prth
Edward Harned
Ranch Hand

Joined: Sep 19, 2005
Posts: 291

Application servers (Tomcat, etc.) generally do not permit the use of threads within the applications. The servers take care of multi-threading. Running your own threads often leads to problems.


Ed's latest article: A Java Parallel Calamity http://coopsoft.com/ar/Calamity2Article.html
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
Well, Tomcat does not prevent you from creating Threads but as Edward said, you can get into trouble.

If your number of users really is large you would not want to let them arbitrarily create Threads. An approach that works just fine for 3 or 4 simultaneous requests could crash with 100.

How about some central mechanism to allow only a few running at any given time and forcing additional requests to wait or "try again later."

How long do you expect a request to take, either to complete or clearly fail? Keeping a request waiting for more than a minute or so is contrary to good web design.

Bill
Adam Smolnik
Ranch Hand

Joined: Apr 15, 2009
Posts: 63
Hey.

Please, look at similar discussion.
http://www.coderanch.com/t/233985/Threads-Synchronization/java/Running-multi-threaded-java-program

I don't agree with previous opinions, however I agree with Ulf Dittmer:

"I don't agree with the notion of not using threads in web apps. Using threads (or Tasks or Futures) one can start asynchronous operations without making the user wait for the response page."


I often used Executors, not raw Threads, for managing limited resources like threads, of course. But it requires carefulness and some experience, especially with cancelling or terminating tasks and to safe shutdown Executors before servlet will be destroyed.

For example, JAX-WS takes advantage of similar mechanism to handle asynchronous client invocation, AJAX libraries, Quartz schedulers as well.

But you must remember: If you propel a new activity or a task explicitly via Threads or implicitly via Executors in some container YOU are responsible for managing, closing and clearing it.

Adam


SCJP, SCWCD, SCBCD, SCDJWS
partha naveen
Ranch Hand

Joined: Jul 17, 2008
Posts: 32
Thanks for the replies. This makes an interesting discussion. However what are the alternatives if I wish to avoid threads, because my user base is indeed large and there could be more than 1000 concurrent users at any point of time. The application code does a piece of work that invokes an API call via a client jar that internally makes a HTTP call over the network. This call is synchronous and awaits for a response. There are situations where the wait exceeds expectations and then within minutes the server is overwhelmed with requests finally leading to tomcat not being able to process any request.

In order to timeout that request I was intending to use FutureTask. However I agree to the notion of using Tomcat threadpools rather than creating new threads. The question that comes up now is this. Supposing I am using the tomcatThreadPool for executing the API call and applying timeout over it, would it mean that for each such request the thread will be killed after a timeout or a normal processing ?

I need to create a new thread at the start of the process of API call, use this thread to make the API call and suspend the current thread for few seconds till the new thread either timeouts or gets the result from API. Can I use tomcatThreadPool for this ? If yes how?
Adam Smolnik
Ranch Hand

Joined: Apr 15, 2009
Posts: 63
Hey.

There are another important aspects of your problem, namely whether you need perform only "one way" invocations of your "API call via a client jar that internally makes a HTTP call over the network", that is to only fire/trigger the task and then ignore response/lack of the response from the one OR you want to confirm or use the answer from the task for building response to Tomcat/container client directly.

In "one way" invocation case I would prefer using of the Executors although.

"Supposing I am using the tomcatThreadPool for executing the API call and applying timeout over it, would it mean that for each such request the thread will be killed after a timeout or a normal processing ?" - it is Tomcat's internal consideration how to cope with that problem. You have nothing to do with it.

Consider another approach:
http://tomcat.apache.org/tomcat-6.0-doc/aio.html

Adam
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: use of FutureTask
 
Similar Threads
Thread throwing an exception
Using FutureTask with Tomcat's thread pool
How can I distinguish between a timeout and other types of exceptions when executing a statement?
calling join() right after start()
thread