Re: How many threads?

shakah wrote:
On Jul 30, 7:28 pm, Roedy Green <see_webs...@xxxxxxxxxxxxxxxxxxxx>
wrote:

The optimal choice could change over time, even within a single run.



I think that your problem calls for a blocking-queue/thread-pool
solution, with possibly an upper-bound to the number of threads --
IMHO, you're unlikely to exhaust a local resource (e.g. CPU or memory,
assuming a reasonably up-to-date box) given the amount of idle time
you'll encounter waiting for I/O while making asynch requests over the
Internet.

Besides making use of the API in java.util.concurrent, I think you've identified one of the requirements yourself in the line I quoted above: change.

Think about designing for change, and which design patterns support high change situations. The Strategy Pattern, for example. If you make your "threading strategy" something that can be configured on the fly, then I think you might have more ability to change things as the code (and the user requirements) evolve.

You can start off with an ExecutorService from java.util.concurrent like ThreadPoolExecutor, and then as you learn more substitute your own custom, well-tuned implementation.

.