ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Malin (Jira)" <j...@apache.org>
Subject [jira] [Closed] (OFBIZ-11200) Refactoring old job process
Date Sat, 22 Feb 2020 17:55:00 GMT

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

Nicolas Malin closed OFBIZ-11200.
    Fix Version/s: Upcoming Branch
       Resolution: Done

After 6 month on production site without problem and real benefit on the database average,
I close this task and commit it trunk.

> Refactoring old job process
> ---------------------------
>                 Key: OFBIZ-11200
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-11200
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Nicolas Malin
>            Assignee: Nicolas Malin
>            Priority: Minor
>              Labels: job, service
>             Fix For: Upcoming Branch
>         Attachments: OFBIZ-11200.patch
> Currently to purge old job, we use the thread job manager to check if some job need to
be run and if the pool is empty, check the old job to purge.
> I detected a problem when you have many job's server and two pools.
> In my case, I have a first pool that run regular job and a second that receive huge asynchrone
services (by persist call).
> Server who manage the second pool have rarely the possibility to purge their jobs that,
by the way, increase JobSandbox table
> Server who manage the first pool, call often the purge process, but the table size generate
a long query time to purge few element. Long query time, run often, this purge process consume
15% of the database load (with correct reindex)
> After analyze, I propose this refactoring :
> * When you call JobSandbox table for a purge, use a limit on the query with the max thread
pool because when you have the database return, you purge only with this limit so this help
the database to not scan the whole table. Other small improvement, do not sort the result
(no functional  gain). With this each query pass to 3.5s at 0.30s (on postgres).
> * Purge by the pool thread is nice, each server can only purge their own job (filtered
on run_by_instance_id), to help an overloaded server, I was rehabiliting service purgeOldJobs
that you can run with specific parameter to make assistance.
> * Last, all job services are historical on class org.apache.ofbiz.service.ServiceUtil,
I moved them all in a new dedicate class org.apache.ofbiz.service.job.JobServices

This message was sent by Atlassian Jira

View raw message