[ https://issues.apache.org/jira/browse/CASSANDRA-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14286419#comment-14286419 ]
Krzysztof Styrc commented on CASSANDRA-8583: -------------------------------------------- I've made some deeper look at these 6 Thread.start() use cases. Cases 1), 2) and 4) create threads for short-running tasks, which might cause some delays in their context (InputStream decompression; SSTable write to disk, setting timeout 5s to read version from the stream; respectively). {{org.apache.cassandra.streaming.ConnectionHandler}} creates separate thread for handling incoming/outgoing messages. One ConnectionHandler is created per StreamSession ("streaming one or more section of one or more sstables to a specific remote node"). It also seems a relatively short-running task to me. Is that correct? Of course it depends on how many sections of how many sstables. Names of the cases 5) and 6) suggest long-running operation, so {{Thread(...).start()}} seems valid. To sum up: Cases 1) 2) and 4) are valid for this issue. I'm not sure about case 3). > Check for Thread.start() > ------------------------ > > Key: CASSANDRA-8583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8583 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Robert Stupp > Priority: Minor > > Old classes sometimes still use > {noformat} > new Thread(...).start() > {noformat} > which might be costly. > This ticket's about to find and possibly fix such code. > Locations in code worth to investigate (IMO). This list is not prioritized - > it's just the order I've found "Thread.start()" > # > {{org.apache.cassandra.streaming.compress.CompressedInputStream#CompressedInputStream}} > creates one thread per input stream to decompress in a separate thread. If > necessary, should be easily replaceable with a thread-pool > # > {{org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter#SSTableSimpleUnsortedWriter(java.io.File, > org.apache.cassandra.config.CFMetaData, > org.apache.cassandra.dht.IPartitioner, long)}} creates one thread per write. > If necessary, should be easily replaceable with a thread-pool > # {{org.apache.cassandra.streaming.ConnectionHandler.MessageHandler#start}} > creates one thread. If necessary, should be easily replaceable with a > thread-pool. > # {{org.apache.cassandra.net.OutboundTcpConnection#handshakeVersion}} creates > one thread just to implement a timeout. Not sure why not just using > {{Socket.setSoTimeout}} > # > {{org.apache.cassandra.service.StorageService#forceRepairAsync(java.lang.String, > org.apache.cassandra.repair.messages.RepairOption)}} creates one thread per > repair. Not sure whether it's worth to investigate this one, since repairs > are "long running" operations > # {{org.apache.cassandra.db.index.SecondaryIndex#buildIndexAsync}} creates a > thread. Not sure whether it's worth to investigate this one. > Beside these, there are threads used in {{MessagingService}} and for > streaming (blocking I/O model). These could be changed by using non-blocking > I/O - but that's a much bigger task with much higher risks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)