[ https://issues.apache.org/jira/browse/CASSANDRA-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133110#comment-14133110 ]
Benedict commented on CASSANDRA-7705: ------------------------------------- Patch available [here|https://github.com/belliottsmith/cassandra/tree/7705-resourcemgmt] This patch traps reference leaks as well as double-releasing references. This version only modifies SSTableReader resource management, but it can be rolled out for any heavy-weight objects we manage, i.e. all instances of RefCountedMemory except those stored in SerializingCache. > Safer Resource Management > ------------------------- > > Key: CASSANDRA-7705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7705 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Fix For: 3.0 > > > We've had a spate of bugs recently with bad reference counting. these can > have potentially dire consequences, generally either randomly deleting data > or giving us infinite loops. > Since in 2.1 we only reference count resources that are relatively expensive > and infrequently managed (or in places where this safety is probably not as > necessary, e.g. SerializingCache), we could without any negative consequences > (and only slight code complexity) introduce a safer resource management > scheme for these more expensive/infrequent actions. > Basically, I propose when we want to acquire a resource we allocate an object > that manages the reference. This can only be released once; if it is released > twice, we fail immediately at the second release, reporting where the bug is > (rather than letting it continue fine until the next correct release corrupts > the count). The reference counter remains the same, but we obtain guarantees > that the reference count itself is never badly maintained, although code > using it could mistakenly release its own handle early (typically this is > only an issue when cleaning up after a failure, in which case under the new > scheme this would be an innocuous error) -- This message was sent by Atlassian JIRA (v6.3.4#6332)