Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZOOKEEPER-4309 QuorumCnxManager's ListenerHandler thread leak #1705

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -957,8 +957,13 @@ public void run() {
new ListenerHandler(address, self.shouldUsePortUnification(), self.isSslQuorum(), latch))
.collect(Collectors.toList());

ExecutorService executor = Executors.newFixedThreadPool(addresses.size());
listenerHandlers.forEach(executor::submit);
final ExecutorService executor = Executors.newFixedThreadPool(addresses.size());
Copy link
Contributor

Choose a reason for hiding this comment

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

what about creating a shared ExecutorService, as a field in this class ?
this way it will be clearer the life cycle of this pool.

also, probably it would be worth to not use a pool in case of a list of addresses of size 1, but this may be a follow up work

Copy link
Contributor Author

Choose a reason for hiding this comment

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

what about creating a shared ExecutorService, as a field in this class ?

I was thinking the same, but then I've found https://github.com/franz1981/zookeeper/blob/b4f9aab099880ba8ef08eaff697debe6cdeae057/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/Leader.java#L456-L468 and see that other parts in the ZK code just do it right without any hook to check for Thread "liveness".

I believe having a shared pluggable executor service could worth for embedded use cases, where people would like to keep control on thread creation, instead.

Choose a reason for hiding this comment

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

what about creating a shared ExecutorService, as a field in this class ?
this way it will be clearer the life cycle of this pool.

also, probably it would be worth to not use a pool in case of a list of addresses of size 1, but this may be a follow up work

we can use a global shared thread pool just as what we do in spring. For example we use @component annotation to register a pool.
however there's a question we need figure it out if the pool is io computed pool or a cpu computed pool.
I think that is io computed pool because we use to accept ticket there.
@eolivelli

Copy link
Contributor

Choose a reason for hiding this comment

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

let's stick with this patch.
we can improve things later

try {
listenerHandlers.forEach(executor::submit);
} finally {
// prevent executor's threads to leak after ListenerHandler tasks complete
executor.shutdown();
}

try {
latch.await();
Expand Down