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

----


---

Reply via email to