[
https://issues.apache.org/jira/browse/HBASE-23918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17048672#comment-17048672
]
Mark Robert Miller commented on HBASE-23918:
--------------------------------------------
I chose to do this via the Java assert keyword.
asserts should not be turned on in production systems.
Tests would fail if run without asserts turned on.
At the end of the constructor for an Object I needed to track:
{code:java}
assert ObjectReleaseTracker.track(this);
{code}
At the end of the close or shutdown method:
{code:java}
assert ObjectReleaseTracker.release(this);
{code}
At the end of each test:
{code:java}
/**
* @return null if ok else error message
*/
String ObjectReleaseTracker.checkEmpty()
{code}
If checkEmpty finds objects that have not been released, it lists them, shows
the stacktrace for the code origin, and then you can fail the test.
> Track sensitive resources to ensure they are closed and assist devs in
> finding leaks.
> -------------------------------------------------------------------------------------
>
> Key: HBASE-23918
> URL: https://issues.apache.org/jira/browse/HBASE-23918
> Project: HBase
> Issue Type: Improvement
> Reporter: Mark Robert Miller
> Priority: Major
>
> Closing some objects is quite critical. Issues with leaks can be quite
> slippery and nasty and growy. Maintaining close integrity is an embarrassing
> sport for humans.
> In the past, those 3 thoughts led me to start tracking objects in tests to
> alert of leaks. Even with an alert though, the job of tracking down all of
> the leaks just based on what leaked was beyond my skill. If it's beyond even
> one devs skill that is committing, that tends to end up trouble. So I added
> the stack trace for the origin of the object. Things can still get a bit
> tricky to track down in some cases, but now I had the start of a real
> solution to all of the whack-a-mole games I spent too much time playing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
