[ https://issues.apache.org/jira/browse/CASSANDRA-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Jirsa updated CASSANDRA-14877: ----------------------------------- Fix Version/s: (was: 3.11.4) (was: 3.0.18) (was: 2.2.14) (was: 2.1.21) (was: 4.0) 4.x 3.11.x 3.0.x 2.2.x 2.1.x > StreamCoordinator "leaks" threads > --------------------------------- > > Key: CASSANDRA-14877 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14877 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Reporter: Massimiliano Tomassi > Assignee: Massimiliano Tomassi > Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.x > > > Since Cassandra 2.1, streaming sessions are started by running a > StreamSessionConnector task for each session in a dedicated executor (a > static field of StreamCoordinator). > That executor is initialized with > DebuggableThreadPoolExecutor.createWithFixedPoolSize, which means that once > created (up to the given limit of the number of logical cores), its threads > are kept alive for Integer.MAX_VALUE seconds. > This practically means that once a node needs to establish streaming sessions > to n other nodes, it will create Math.min(n, numLogicalCores) > StreamConnectionEstablisher threads that will stay parked forever after > initializing (not completing) the session. > It seems preferable to replace > DebuggableThreadPoolExecutor.createWithFixedPoolSize with > DebuggableThreadPoolExecutor.createWithMaximumPoolSize which allows providing > a saner keep-alive period (e.g. a minute). > That's also what createWithFixedPoolSize's Javadoc recommends: If (most) > threads are expected to be idle most of the time, prefer createWithMaxSize() > instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org