New feature - a concurrency limiter

[spkrka]

No description provided.

[odsod]

Consider adding missing newline.

[spkrka]

done

[odsod]

+1

Very nice, this will come in handy.

[pettermahlen]

Looks good, a couple of questions, though:

• did you consider (optionally) using a BlockingQueue, so as to enforce size limits? The add() method of a BlockingQueue will throw when trying to add beyond a certain limit.
• the size() method of ConcurrentLinkedQueue is pretty slow, according to its javadocs, so calling numQueued() may be expensive. Should that be documented somehow?

[spkrka]

@pettermahlen Thanks for the comments.

I pushed some new commits which leads to:

• Creating a limiter requires specifying a maximum queue size. Unbounded queues are dangerous after all.
• Calling add may throw an exception if the maximum queue size is exceeded.
• Instead of calling queue.size(), the code tracks the size manually with an AtomicInteger.

[rschildmeijer]

I don't like mixing sync exc with async exc.

[rouzwawi]

I'm a bit unsure if the calls to pump() from the future callback in invoke() is such a good idea. It will cause the callables in the queue to be invoked from arbitrary other thread pools in the application using this utility.

It might be OK from a cpu utilization view since the callables should return immediatly, but can cause confusion for other surprising reasons.

[spkrka]

Yes, callables will indeed run on seemingly random threads. I don't think this is enough of a problem to block releasing the feature. If it turns out to be a real problem we can create a new API that lets people pass in an executor to run on.