[
https://issues.apache.org/jira/browse/FINERACT-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Chaudhary resolved FINERACT-2915.
------------------------------------------
Resolution: Fixed
> Recalculate Interest For Loans job skips loans because its paging cursor
> advances by page size
> ----------------------------------------------------------------------------------------------
>
> Key: FINERACT-2915
> URL: https://issues.apache.org/jira/browse/FINERACT-2915
> Project: Apache Fineract
> Issue Type: Bug
> Components: Job Scheduler, Loan
> Affects Versions: 1.15.0
> Reporter: Abhishek Chaudhary
> Assignee: Abhishek Chaudhary
> Priority: Major
> Fix For: 1.17.0
>
>
> When the job runs with an {{officeId}} parameter,
> {{RecalculateInterestForLoanTasklet}} pages through loans with
> {{maxLoanIdInList += pageSize + 1}}. That moves the cursor by a fixed number
> of ids, not to the last loan id fetched. The query
> ({{fetchLoansForInterestRecalculation}}) selects {{l.id >= ? ... GROUP BY
> l.id LIMIT ?}} with no {{ORDER BY}}.
> This is the default setup: job 17 is seeded with {{officeId=1}},
> {{thread-pool-size=10}} and {{batch-size=100}}, which gives a page size of
> 1000.
> * *Rows in id order:* with 5000 consecutive eligible loans, pages cover
> 1-1000, 1001-2000, then 2002-3001. Loans 2001, 3002 and 4003 are never
> recalculated, and the same loans are skipped on every run.
> * *Rows in arbitrary order:* without {{ORDER BY}}, PostgreSQL may return the
> grouped rows in any order. Any unprocessed loan below the cursor is then
> skipped.
> * *Floating-rate loans* are not excluded once recalculated, so they can be
> processed more than once in a run.
> *Expected:* page by the last fetched loan id ({{l.id > ?}}) and order the
> query by {{l.id}}, as
> {{SavingsAccountReadPlatformServiceImpl.getAccountsIdsByStatusPaged}} already
> does.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
