Skip to content

Don't override finalize() and reduce locking in LoadBalancingPool and ReferenceCountedResourceHandler#3874

Merged
drcrallen merged 4 commits intoapache:masterfrom
metamx:no-finalize
Feb 7, 2017
Merged

Don't override finalize() and reduce locking in LoadBalancingPool and ReferenceCountedResourceHandler#3874
drcrallen merged 4 commits intoapache:masterfrom
metamx:no-finalize

Conversation

@leventov
Copy link
Copy Markdown
Member

A follow-up of #3631

As LoadBalacingPool was used only for pooling memcache clients, it is specialized as MemcacheClientPool.

* connection using a linear search over a simple array, than fiddling with PriorityBlockingQueue. This also allows
* to reduce locking.
*/
private final CountingHolder[] connections;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the only major difference I see , older class used PriorityBlockingQueue instead to have logN get operations. I guess, size of this pool is usually very small so that difference shouldn't matter

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@himanshug we use 8 clients, unlikely anybody else uses more.

The other change is using Cleaner instead of overriding finalize().

@himanshug
Copy link
Copy Markdown
Contributor

@leventov looks good, some tests would be nice.

…Pool. Add tests for ReferenceCountingResourceHolder and MemcacheClientPool
@leventov
Copy link
Copy Markdown
Member Author

@himanshug added tests

@himanshug
Copy link
Copy Markdown
Contributor

@leventov thanks

👍

throw new ISE("Already closed!");
}
if (refCount.getAndIncrement() <= 0) {
refCount.decrementAndGet();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When two or more threads call increment() on already closed holders, it looks that some threads might pass this checking accidently because above two operations are not atomic.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks! Fixed

@jihoonson
Copy link
Copy Markdown
Contributor

The latest patch looks good to me.

@Override
public void run()
{
try (Releaser r = resourceHolder.increment()) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a start gate here? or else on an overburdened CI system the threads could easily all start in sequence without actually racing anything

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like a 100ct CountdownLatch?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@drcrallen yes, I think it would be good. But PR is already merged.

Copy link
Copy Markdown
Contributor

@gianm gianm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

{
synchronized (lock) {
if (refcount <= 0) {
while (true) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spins are cool.

image

@drcrallen drcrallen merged commit ca9f0e2 into apache:master Feb 7, 2017
@drcrallen drcrallen deleted the no-finalize branch February 7, 2017 01:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants