GitHub user stevedlawrence opened a pull request:
https://github.com/apache/incubator-daffodil/pull/4
Ensure marks are always returned to the markpool
MarkPool leaks have been notoriously difficult to track down. This is
partly due to the fact that we don't check for leaks until the very end
of parsing, so we don't know there is a leak until well after it has
happened, giving us little information about where or why.
Additionally, we do not currently return leaked marks. Since marks are
stored in a ThreadLocal, and since they aren't returned, leaked marks
are forever leaked, and every subsequent parse will cause an assertion
due to the final validation check.
This modifies the users of marks to always return marks so the
processing could potentially continue if an API user wanted to (like in
the case of NiFi). This also throws an invariant failed assertion a mark
is leaked so we know exactly where it occurred. Furthermore, if an
exception was the cause of a mark leak, the stack trace of the exception
is captured to help determine the original cause.
DAFFODIL-1862
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/stevedlawrence/incubator-daffodil
daffodil-1862-markpool
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-daffodil/pull/4.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4
----
commit ae518d6c5e5f99189b56c70a19739f272871fec9
Author: Steve Lawrence <[email protected]>
Date: 2017-11-06T22:59:54Z
Ensure marks are always returned to the markpool
MarkPool leaks have been notoriously difficult to track down. This is
partly due to the fact that we don't check for leaks until the very end
of parsing, so we don't know there is a leak until well after it has
happened, giving us little information about where or why.
Additionally, we do not currently return leaked marks. Since marks are
stored in a ThreadLocal, and since they aren't returned, leaked marks
are forever leaked, and every subsequent parse will cause an assertion
due to the final validation check.
This modifies the users of marks to always return marks so the
processing could potentially continue if an API user wanted to (like in
the case of NiFi). This also throws an invariant failed assertion a mark
is leaked so we know exactly where it occurred. Furthermore, if an
exception was the cause of a mark leak, the stack trace of the exception
is captured to help determine the original cause.
DAFFODIL-1862
----
---