V2.0.2 Release Notes

  • 1. Self-developed scheduling components to remove Quartz dependence: on the one hand, to simplify the system and reduce redundant dependence; on the other hand, to provide system controllability and stability;
    • Trigger: A node triggers periodically, running events such as delayQueue.
    • Scheduling: cluster competition, load cooperative processing, lock competition-update trigger information – push time wheel – lock release – lock competition;
  • 2. Reconstruction of the underlying table structure: removed 11 Quartz related tables, and optimized and combed the existing table structure;
  • 3. Change the primary key of task logs to long data type to prevent data overflow in the case of massive logs;
  • 4. Low-level thread model reconstruction: Remove Quartz thread pool to reduce system thread and memory overhead;
  • 5, user management: support online management system users, there are administrators, ordinary users two roles;
  • 6. Permission management: Permission control is carried out in the dimension of the executor. The administrator has full permission, and common users are allowed to perform related operations only after the permission is assigned to the executor.
  • 7. Scheduling thread pool parameters tuning;
  • 8, registry index optimization, alleviate the locking table problem;
  • 9. Add Jboot executor Sample project;
  • 10, task list optimization, support according to the “task status”, “responsible person” attribute screening task;
  • 11. Interactive optimization of task log list, merging operation button into split button;
  • 12. Upgrade project dependencies to newer stable versions, such as Spring, Springboot, Groovy, XXL-RPC, etc. And clear the redundant POM;
  • 13. Upgrade XXL-RPC to a later version, and fix the problem of long connection redundant creation caused by remote service unavailable during proxy service initialization;
  • 14. Fixed the out-of-order problem in TIDB of the scheduling report on the home page;
  • 15. The timeout time of bidirectional communication between the dispatching center and the actuator is adjusted to 3S;
  • 16. Scheduling component destruction process optimization: stop the scheduling thread first, wait for the completion of time wheel memory task processing, and finally destroy the time wheel thread;
  • Actuator callback thread optimization, callback address is empty when the destruction problem fixed;
  • 18, HttpJobHandler optimization, response data specified UTF-8 format, avoid Chinese garble;
  • 19. Code optimization: Change the variable type of ConcurrentHashMap to ConcurrentMap to avoid compatibility problems caused by different implementations of different versions;

Introduction to the

Xxl-job is a lightweight distributed task scheduling platform, whose core design goal is rapid development, simple learning, lightweight and easy to expand. Now open source and access to many companies online product lines, out of the box.

Enter the image title here

features

  • 1, simple: support CRUD operation through Web page, simple operation, one minute to get started;
  • 2. Dynamic: support dynamic modification of task status, start/stop task, and termination of running task, effective immediately;
  • 3. HA of the dispatching center (central) : The dispatching center adopts the centralized design. The dispatching center develops its own dispatching components and supports cluster deployment to ensure the HA of the dispatching center.
  • 4. Executor HA (distributed) : Tasks are executed in distributed mode. Task executors support cluster deployment to ensure task HA.
  • 5. Registry: The executor automatically registers tasks periodically, and the scheduling center automatically discovers registered tasks and triggers execution. At the same time, it also supports manual input actuator address;
  • 6. Flexible capacity expansion and reduction: Once a new actuator goes online or offline, tasks will be reassigned in the next scheduling;
  • 7. Routing policies: When the executor is deployed in a cluster, various routing policies are provided, including the first, last, polling, random, consistent HASH, least Frequently used, most recently unused, failover, and busy failover.
  • 8. Failover: If the task routing policy is set to Failover, if a machine in the actuator cluster fails, the system automatically switches over to a normal actuator to send scheduling requests.
  • 9. Blocking processing strategy: the processing strategy when the scheduling is too dense for the executor to process, including single-machine serial (default), discarding subsequent scheduling, scheduling before overwriting;
  • 10, task timeout control: support custom task timeout, task running timeout will actively interrupt the task;
  • 11. Retry when a task fails: Supports user-defined task retry times. When a task fails, the system automatically retries the task based on the preset retry times. The sharding task supports failure retry of the sharding granularity.
  • 12. Task failure alarm; By default, email failure alarms are provided, and expansion interfaces are reserved to facilitate the expansion of SMS and nailing alarms.
  • 13. Fragment broadcast task: When the task routing policy is selected as “fragment broadcast” in the executor cluster deployment, a task scheduling task will broadcast to trigger all executors in the cluster to execute a task, and fragment tasks can be developed according to the fragment parameters.
  • 14. Dynamic sharding: The fragment broadcast task is sharding based on the executor. Dynamic expansion of the executor cluster is supported to dynamically increase the number of fragments and coordinate business processing. It can significantly improve the task processing capability and speed when performing large data operations.
  • 15. Event triggering: In addition to “Cron mode “and” Task dependent Mode “, event based task triggering mode is supported. The scheduling center provides the API service to trigger a single task execution, which can be flexibly triggered based on service events.
  • 16. Task progress monitoring: Support real-time monitoring of task progress;
  • 17, Rolling real-time log: support online view of scheduling results, and support Rolling real-time view of the complete execution log output by the actuator;
  • 18, GLUE: Provide Web IDE, support online development task logic code, dynamic release, real-time compilation effect, omit the process of deployment online. Supports 30 versions of historical version backtracking.
  • 19. Script tasks: Support the development and running of script tasks in GLUE mode, including Shell, Python, NodeJS, PHP, PowerShell and other scripts;
  • Command line tasks: natively provides a generic command line task Handler (Bean task, “CommandJobHandler”); The business side only needs to provide the command line;
  • 21. Task dependency: Support the configuration of subtask dependency. When the parent task is completed and successfully executed, it will actively trigger the execution of a subtask.
  • 22. Consistency: The “Scheduling center” ensures the consistency of distributed scheduling of the cluster through DB lock.
  • 23. User-defined task parameters: support online configuration of scheduling task input parameters, effective immediately;
  • 24, scheduling thread pool: scheduling system multi-thread trigger scheduling operation, to ensure the accurate execution of scheduling, not blocked;
  • 25. Data encryption: encrypt the communication between the dispatching center and the actuator to improve the security of scheduling information;
  • 26. Email alarm: support email alarm when the task fails, support configuring multiple email addresses to send alarm emails;
  • 27. Push Maven central repository: The latest stable version will be pushed to Maven central repository for convenient user access and use;
  • 28, running report: support real-time view of running data, such as the number of tasks, scheduling times, number of actuators, etc. And scheduling report, such as scheduling date distribution map, scheduling success distribution map, etc.
  • 29. Full asynchrony: full asynchrony design and implementation of task scheduling process, such as asynchronous scheduling, asynchronous operation, asynchronous callback, etc., which can effectively cut traffic peak for intensive scheduling and theoretically support the operation of tasks of any length;
  • 30. Cross-platform: natively provides generic HTTP task handlers (Bean tasks, “HttpJobHandler”); The business side only needs to provide HTTP links, regardless of language or platform;
  • 31. Internationalization: The scheduling center supports internationalization Settings and provides two optional languages, Chinese and English. The default is Chinese.
  • Containerization: provide official Docker image, and real-time update push DockerHub, further realize the product out of the box;
  • 33, thread pool isolation: scheduling thread pool isolation split, Slow tasks automatically demoted into the “Slow” thread pool, avoid running out of scheduling threads, improve system stability;
  • 34, user management: support online management system users, there are administrators, ordinary users two roles;
  • 35, permission control: executive dimension permission control, administrators have full permissions, common users need to assign executive permission before allowing related operations;

The document address

  • Chinese document

Technical communication

  • Community communication