[
https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421495#comment-17421495
]
Mark Bean commented on NIFI-8727:
---------------------------------
Correction: After running for about 24 hours, NiFi was restarted and there were
no "Found unknown file" messages. The ones noted previously might be
attributable to claims that just recently became empty, but before the cleanup
process executed.
Either way, the symptom of a constantly growing content repository - resulting
from claims not reaching a claimant count of 0 - is no longer observed.
Note: the proposed solution will result in a StandardRepositoryRecord having a
type of UPDATE rather than the current logic having a value of CREATE.
> claimantCount will never decrement to zero
> ------------------------------------------
>
> Key: NIFI-8727
> URL: https://issues.apache.org/jira/browse/NIFI-8727
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.12.0, 1.13.0, 1.12.1, 1.13.1, 1.13.2
> Environment: linux
> Reporter: wangliqiang
> Priority: Major
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> When running my processor code below :
> {code:java}
> //originalFlowFile has content , so ClaimantCount=1
> FlowFile multiFlowFile = session.clone(originalFlowFile); // claim count
> +1，so ClaimantCount=2
> multiFlowFile = session.write(multiFlowFile, new OutputStreamCallback() {
> @Override
> public void process(OutputStream out) throws IOException {
> IOUtils.write(tvMultiAlbumJson, out, Charset.forName("UTF-8"));
> }
> });//the new content will resuse the same resource claim , so ClaimantCount=3
> //At this point we have two flowfile and two contentClaim ，and ClaimCount=3.
> //When this two flowfiles dropped，the claimantCount should decrement to
> 0，however the result is ClaimantCount=1！
> //If we use "sh nifi.sh diagnostics --verbose dump.log" to get a dump log，we
> will find some info like this “default/465/1623853427574-10705, Claimant
> Count = 1, In Use = true, Awaiting Destruction = false, References (0) = []”
> //And the file “default/465/1623853427574-10705” will never be archived，and
> will never be destroyed，and the content_repository will use more storage than
> it configs.{code}
> The above is a sort of phenomenon. The reason is the code below：
> {code:java}
> //session.clone
> public FlowFile clone(FlowFile example, final long offset, final long size) {
> .....................................
> final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null); //here the originalFlowFileRecord of record
> is null
> .....................................
> return clone;
> }
> //session.commit
> private void updateClaimCounts(final RepositoryRecord record) {
> ..........................................................
> if (record.isContentModified()) {
> decrementClaimCount(originalClaim); //here the originalClaim is null
> }
> }{code}
> Perhaps we should not use session.clone like that，but without official note
> it will sometimes happen to be used.
> So i change "final StandardRepositoryRecord record = new
> StandardRepositoryRecord(null)" to "final StandardRepositoryRecord record =
> new StandardRepositoryRecord(null, currRec);"
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
