5

I have a task which might last up to 100ms that I want to kick off at the start of handling a request and grab the result when I need it later on. I don't want to block and extend every request by this amount.

In a vanilla Java app I'd create a ExecutorService and run it as a Callable<T> using the Future<T> to get the result later on.

Since Tomcat maintains its own pool of threads, should I be trying to coordinate with it? In other words, is my ExecutorService pool competing with Tomcat's threads? Is this an issue? Is there an advantage to piggybacking onto Tomcat's pool somehow?

Any advice from someone who has similar experience would be much appreciated. Also I'm not interested at this point in adding additional dependencies like Spring, etc.

4

1 回答 1

4

should I be trying to coordinate with it?

No, Tomcat pool is dedicated to Tomcat

In other words, is my ExecutorService pool competing with Tomcat's threads?

Not at all. It's your pool.

Is this an issue? Is there an advantage to piggybacking onto Tomcat's pool somehow?

There's no issues with maintaining custom application pool as soon as it doesn't produce millions of threads. Just make sure to provide threads with daemon status so tomcat shutdown scripts wouldn't complain about 'can't stop Tomcat'

于 2013-07-12T21:26:46.307 回答