[commons-imaging] Git Push Summary

Repository: commons-imaging Updated Branches: refs/heads/release [deleted] 6de93545a

[1/4] commons-pool git commit: POOL-356 add unit test for the deadlock

Repository: commons-pool Updated Branches: refs/heads/master d4e0e8822 -> 75a47ee1f POOL-356 add unit test for the deadlock Project: http://git-wip-us.apache.org/repos/asf/commons-pool/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-pool/commit/60a041d3 Tree: http://git-wip-us.apa

[3/4] commons-pool git commit: POOL-340 unit test contributed by Pavel Kolesov

POOL-340 unit test contributed by Pavel Kolesov Project: http://git-wip-us.apache.org/repos/asf/commons-pool/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-pool/commit/ad9a0d89 Tree: http://git-wip-us.apache.org/repos/asf/commons-pool/tree/ad9a0d89 Diff: http://git-wip-us.apache.org/

[4/4] commons-pool git commit: POOL-340 correct validateObject

POOL-340 correct validateObject With the corrected behaviour of ValidateObject we now pass the test. Seems like the original error was already fixed in our last few commits. Project: http://git-wip-us.apache.org/repos/asf/commons-pool/repo Commit: http://git-wip-us.apache.org/repos/asf/commons-p

[2/4] commons-pool git commit: POOL-356 fix deadlock on massive concurrent requests

POOL-356 fix deadlock on massive concurrent requests Happens when blockWhenExhausted is active. The idleObjects.takeFirst and .pollFirst operations perform a lock. So if the pool is empty and the MaxTotal is hit we end up having multiple Threads perform a lock internally via idleObjects.takeFirst(