[
https://issues.apache.org/jira/browse/CASSANDRA-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283679#comment-14283679
]
Sylvain Lebresne commented on CASSANDRA-8583:
---------------------------------------------
Without having looked at all places, I'm not entirely convinced that all of
them should be replaced. To the best of my knowledge there is nothing wrong
with {{new Thread(...).start()}} if you know that you want a dedicated thread
and the time to start it is irrelevant (either because that thread will live
for the lifetime of the application anyway, or because the place where it's
started is not time sensitive). Let's not blindly replace it all with thread
pools because we can.
> 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)
