Solving performance problems in parallel processing

[nbluis]

Hi.

In this patch, I first adjusted the problem described in issue #256.

But even after this, I did some testing and the parallel performance was still much lower than expected (set in GeoApiContextProvider.setQueryRateLimit)

After a few more tests, I identified that the problem was in the delay between take operations in RateLimitExecutorService.

The ThreadPoolExecutor documentation, explains the overhead of using the LinkedBlockingQueue as workQueue and suggests the use of SynchronousQueue as a good choice.

To my surprise, when I tested only this change I had incredible results.

I used the example cited by @irineuruiz in #228 with litle changes to perform the test with 500 tries and 50 QPS.

Using LinkedBlockingQueue:
Time taken: 22248
QPS achieved: 22.473930240920534

Using SynchronousQueue:
Time taken: 11467
QPS achieved: 43.60338362256911

Also, I checked that by default the OkHttp Dispatcher uses SynchronousQueue to run. So I think it's a pretty safe change.

This patch fixes #256 and #228 issues and will allows us to achiev the expected QPS.

[nbluis]

Nice. @domesticmouse you have an idea when we will have a new release ?

[domesticmouse]

Release is now in the wild. v0.1.20 is up on search.maven.org.