Details
-
Improvement
-
Status: Open
-
Low
-
Resolution: Unresolved
-
None
-
None
Description
Old classes sometimes still use
new Thread(...).start()
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.