You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Mark Bean (Jira)" <ji...@apache.org> on 2021/09/27 18:04:00 UTC

[jira] [Commented] (NIFI-8727) claimantCount will never decrement to zero

    [ https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420942#comment-17420942 ] 

Mark Bean commented on NIFI-8727:
---------------------------------

I applied the same fix as above. Specifically, modified StandardProcessSession.clone() such that the new repository record included a reference to the current record:

final StandardRepositoryRecord record = new StandardRepositoryRecord(null, currRec);

However, this did not resolve the problem completely. Through additional log messages I added for debugging, I could see that the claimant count went to zero. However, in the flowfile repo (RocksDBFlowFileRepository.determineDestructibleClaims), I noted the "current claim" is destructible, but the "original claim" is not. Yet, when NiFi was restarted, that claim was identified as "Found unknown file" which means there were no flowfiles associated with this claim.


> 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)