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?
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.
SCJP, SCWCD, SCBCD, SCDJWS
Joined: Jul 17, 2008
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?
Joined: Apr 15, 2009
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.