[
https://issues.apache.org/jira/browse/CASSANDRA-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295266#comment-14295266
]
Benedict commented on CASSANDRA-7705:
-------------------------------------
bq. (though they aren't actually anything to do with these commits AFAICT)
My git-foo was weak, this clearly was my mistake.
Committed, thanks!
Also, looking closely at the code I agree with your concern about sharedRef,
but think the whole of StreamingTransfer should have a bit of an overhaul of
its own, to ensure absolute safety including in the face of error. I had a bit
of a go at this, but decided it was a bit meaty for an addendum to this ticket.
So I've filed CASSANDRA-8698
> Safer Resource Management
> -------------------------
>
> Key: CASSANDRA-7705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7705
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: 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)
