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

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

     [ https://issues.apache.org/jira/browse/NIFI-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joe Witt updated NIFI-8727:
---------------------------
    Fix Version/s: 1.15.0

> 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
>            Assignee: Mark Bean
>            Priority: Major
>             Fix For: 1.15.0
>
>   Original Estimate: 96h
>          Time Spent: 1.5h
>  Remaining Estimate: 94.5h
>
> 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)