[
http://mifosforge.jira.com/browse/MIFOS-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61399#action_61399
]
Udai Gupta commented on MIFOS-4082:
-----------------------------------
Conclusion after looking into the existing batch jobs and the date used by them
ApplyHolidayChangesTaskJob - Doesn't matter which date is passed
SavingsIntPostingTaskJob - uses the fireTime passed
LoanArrearsAgingTaskJob - Depends on LoanArrearsTask (which is part of
LoanArrearsAndPortfolioAtRiskTaskJob), it uses the current system date
ApplyCustomerFeeChangesTaskJob - Doesn't matter which date is passed
BranchReportTaskJob - It uses the fireDate (timeInMilis)
LoanArrearsAndPortfolioAtRiskTaskJob - It uses current system Date
ProductStatusJob - It uses the fireDate (timeInMilis)
GenerateMeetingsForCustomerAndSavingsTaskJob - It uses current system Date
The catch up works well with the batch jobs which uses the fireDate, We need to
move system date to recover failure of the batch jobs which uses system date.
These pages need to be updated.
http://mifos.org/functional-specifications/system-processing/batch-jobs
http://mifos.org/documentation/system-administration/managing-batch-jobs
> Batch job execution should use Date from
> org.mifos.framework.components.batchjobs.TaskHelper.execute(long
> timeInMillis) , Not the system date
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MIFOS-4082
> URL: http://mifosforge.jira.com/browse/MIFOS-4082
> Project: mifos
> Issue Type: Improvement
> Components: Batch jobs
> Affects Versions: Release E
> Reporter: Udai Gupta
> Assignee: mifosdeveloperqueue
> Priority: Major
> Fix For: Unscheduled
>
>
> ApplyHolidayChangesHelper uses the system date which will cause problem
> during catch up mechanism (after failure rerun next day).
> long taskStartTime = new DateTimeService().getCurrentDateTime().getMillis();
> Is it intentional?
> org.mifos.framework.components.batchjobs.TaskHelper.execute(long
> timeInMillis), argument is passed in a catchup execution from jobParameter
> date is going to be the date on which the batch job was failure (or haven't
> ran). If this argument is not used correctly then there will be no effect of
> catchup mechanism.
> to understand what Job Instance, Job execution and Job Parameter means read
> http://static.springsource.org/spring-batch/reference/html/domain.html
> We don't know the severity of this issue?
> Previously people used to catchup batch jobs by rerunning them after moving
> the system date.
> There is no change as it was the behaviour of Mifos Batch Jobs before
> Spring/Quartz implementation.
> There is more to investigate here than to implement
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mifosforge.jira.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
