[
https://issues.apache.org/jira/browse/CASSANDRA-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644228#comment-14644228
]
Robert Stupp commented on CASSANDRA-9423:
-----------------------------------------
The patch generally LGTM.
Just a few comments. Feel free to address these on commit.
* Ref.Visitor.run(): move path.clear() + visited.clear() to a finally block of
the enclosing try
* Ref.Visitor: Is it worth to add a check whether a Field is already in the
current {{path}} to detect cyclic references ?
* Ref.getFields(): Check for {{clazz==Class.class ||
java.lang.reflect.Member.class.isAssignableFrom(clazz)}} to exclude these.
AFAIR I had issues with these classes in another project - but cannot remember.
* {{o.a.c.utils.concurrent.WrappedSharedCloseable.Tidy#tidy}} might fail to
free referenced Memory instances, if one free fails. I admit, this is very
unlikely to ever occur.
Nits:
* AlwaysPresentFilter: unused import
* SharedCloseableImpl: missing newline before addTo()
* Ref: STRONG_LEAK_DETECTOR can be null, if DEBUG_ENABLED is false
* Ref.GlobalState: please emphasize ”MUST NOT” in the comment (”… Tidy object
MUST not contain …”)
Unrelated to this ticket. WDYT about this:
{{o.a.c.io.sstable.IndexSummary.IndexSummarySerializer#deserialize}} could
handle Memory safer starting at {{Memory offsets = Memory.allocate(offsetCount
* 4);}}
Similar for {{o.a.c.io.sstable.IndexSummaryBuilder#downsample}} and
{{o.a.c.utils.obs.OffHeapBitSet#deserialize}}.
> Improve Leak Detection to cover strong reference leaks
> ------------------------------------------------------
>
> Key: CASSANDRA-9423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9423
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0.0 rc1
>
>
> Currently we detect resources that we don't cleanup that become unreachable.
> We could also detect references that appear to have leaked without becoming
> unreachable, by periodically scanning the set of extant refs, and checking if
> they are reachable via their normal means (if any); if their lifetime is
> unexpectedly long this likely indicates a problem, and we can log a
> warning/error.
> Assigning to myself to not forget it, since this may well help especially
> with [~tjake]'s concerns highlighted on 8099 for 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
