Skip to content

Conversation

Tim-Brooks
Copy link
Contributor

When an ESSelector is created an underlying nio selector is opened.
This selector is closed by the event loop after close has been
signaled by another thread.

However, there is a possibility that an ESSelector is created and
some exception in the startup process prevents it from ever being
started (however, `close`` will still be called). The allows the
selector to leak.

This commit addresses this issue by having the signaling thread close
the selector if the event loop is not running when close is signaled.

When an ESSelector is created an underlying nio selector is opened. This
selector is closed by the event loop after close has been signalled by
another thread.

However, there is a possibility that an ESSelector is created and some
exception in the startup process prevents it from ever being started
(however, close will still be called). The allows the selector to leak.

This commit addresses this issue by having the signalling thread close
the selector if the event loop is not running when close is signalled.
Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

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

I left a comment but it LGTM.

} catch (InterruptedException e) {
eventHandler.uncaughtException(e);
Thread.currentThread().interrupt();
throw new IllegalStateException("CountDownLatch got interrupted", e);
Copy link
Member

@jasontedor jasontedor Dec 14, 2017

Choose a reason for hiding this comment

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

Can we say something more precise like "selector was interrupted while closing"?

@Tim-Brooks Tim-Brooks merged commit f33f961 into elastic:master Dec 14, 2017
Tim-Brooks added a commit that referenced this pull request Dec 14, 2017
When an ESSelector is created an underlying nio selector is opened. This
selector is closed by the event loop after close has been signalled by
another thread.

However, there is a possibility that an ESSelector is created and some
exception in the startup process prevents it from ever being started
(however, close will still be called). The allows the selector to leak.

This commit addresses this issue by having the signalling thread close
the selector if the event loop is not running when close is signalled.
@Tim-Brooks Tim-Brooks deleted the remove_selector_leak branch November 14, 2018 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Coordination/Network Http and internode communication implementations v6.2.0 v7.0.0-beta1
3 participants