[
https://issues.apache.org/jira/browse/CASSANDRA-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14287268#comment-14287268
]
Robert Stupp commented on CASSANDRA-8583:
-----------------------------------------
[~kstyrc], 3) can run several seconds and maybe longer (sure, depends on amount
of data, disk I/O, net I/O).
Regarding 4) - can you check if using a socket timeout could do the same (on
Linux, Windows, Mac) as the current code? That would eliminate the need for a
separate thread at all.
I'd love to have some numbers whether a thread pool for 1) and 2) is worth the
change. If it turns out, that for example a compaction or flush requires many
threads to be started plus a relatively huge amount of temporarily allocated
system resources ("OS pressure"), I tend to support the change.
> 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)
