The code used a fixed pool size before. The concern is that we keep too many threads live for no reason since the thread is only used to 'get' the value from the Java future and complete the promise. The callback is executed in another context. So basically, we should not need many thread to do this. The idea of the dynamic pool size is that we use only as many thread as we need. Yes, on spike, there might be some extra thread creation, but I think we prefer executing the 20 parallel http call rather than serialize them. Then, the extra threads needed to support the spike will be destroyed to adjust to the minimal pool size needed for the load.

Since the core size is 0, then the pool will always reuse an existing thread if available. Which I think is what we want.

The code I use was inspired form

```java
/**
     * Creates a thread pool that creates new threads as needed, but
     * will reuse previously constructed threads when they are
     * available.  These pools will typically improve the performance
     * of programs that execute many short-lived asynchronous tasks.
     * Calls to <tt>execute</tt> will reuse previously constructed
     * threads if available. If no existing thread is available, a new
     * thread will be created and added to the pool. Threads that have
     * not been used for sixty seconds are terminated and removed from
     * the cache. Thus, a pool that remains idle for long enough will
     * not consume any resources. Note that pools with similar
     * properties but different details (for example, timeout parameters)
     * may be created using {@link ThreadPoolExecutor} constructors.
     *
     * @return the newly created thread pool
     */
    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }
```

but I specified a max value to prevent thread explosion. The downside is that if we reached the maximum threadsize, because of the SynchronousQueue, it will block.

Maybe we could use a ArrayBlockingQueue with (core = max) to reject requests before blocking when we reach both max queue size and max pool size.

Or maybe we let the user specify it :) What do you think?