Java Future API

[Joshua Maurice]

This is my program. I want very much to fidn some good papers or
discussions, or just the standard advice, on this topic.

My company uses the Java Future interface to asynchronously start a
very very big job, mostly implemented in C++. A user at a GUI can
start the operation, and the user at the GUI can cancel the operation.
This cancel GUI click will in turn call Future.cancel. The Future
object is then discarded, and we go along our merry way.

This to me seems to be a classic thread leak. However, if the Future
is started in a thread pool, and that thread pool throttles the number
of active threads, then this will probably work out ok, right? I'm
just concerned about possible spikes in memory usage resulting in out
of memory errors. I really don't like "Oh, but the canceled Future
threads will get scheduled and finish up eventually" nor "The bug we
really need to fix is to make sure that a canceled job notices this
cancel request and quickly terminates."

I almost want a join call on the Future, as it is my understanding
that Future.get on a canceled future will not wait on the job, and
instead immediately throw cancelation exception.

I'm looking for input and advice regarding such things. Is it standard
practice, and robust, to just call cancel and discard it, and rely
upon the threading pool to throttle the number of active jobs, and
code the job to end quickly upon cancelation? Is this reasonable? What
am I missing in this discussion. What papers, books, etc., can I read
to familiarize myself with such situations: basically 'do's and
'don't's for high availability, robust, servers (which is basically my
use case. The user's GUI will exist in its own process and issue
requests to the server process, possibly on another machine, to run
the job).