XXL-JOB: a Java distributed task scheduler with a web console and GLUE

What XXL-JOB solves, and who ends up using it

Cron on a single box is fine until the box restarts or the job needs to run on five machines at once. XXL-JOB answers that with two roles. A scheduling center (xxl-job-admin) owns the trigger calendar and the web console. Executors are separate processes that register themselves with the center and receive trigger requests. The README describes the design goal as "develop quickly and learn simple, lightweight, and easy to expand", and the feature list backs that up with a web-based CRUD console, dynamic start and stop of jobs, and a registry that discovers executors automatically.

The audience is narrower than the feature list suggests. The primary language is Java, the core artifact is published to Maven Central as com.xuxueli:xxl-job-core, and the repository ships xxl-job-executor-samples to show the integration pattern. If your scheduled work already lives in a Spring application, adding an executor is a small change. If your jobs are Python scripts owned by a data team, you are looking at the RESTful OpenAPI or the script handlers rather than a native SDK, and that changes the shape of the work.

How the admin and executor split actually works

The scheduling center is a central component that runs its own scheduling logic and can be deployed as a cluster. Executors register periodically, and the center discovers them and triggers execution. Manual entry of executor addresses is also supported, which matters when auto-registration is blocked by network policy.

Consistency across a clustered admin is handled with a database lock, so a single trigger fires once even with multiple admin instances. Trigger dispatch runs through a thread pool, and the README notes that slow tasks are demoted into a separate "Slow" thread pool so they cannot exhaust the scheduling threads. The whole trigger path is described as asynchronous: dispatch, execution and callback are decoupled, which is how the project claims to absorb bursts of dense scheduling.

On the executor side, routing decides which machine in a cluster takes the work. The options listed include first, last, round robin, random, consistent hash, least frequently used, least recently used, failover and busy transfer. Sharding broadcast is the interesting one: a single trigger fans out to every executor in the cluster, and each one receives a shard index and total, so a large job can be split across machines and the shard count grows as you add executors. Blocking policy is a separate knob, with single-machine serial execution as the default, plus discard-later and cover-earlier alternatives for when triggers arrive faster than the executor finishes.

Installing XXL-JOB and running a first job

The repository layout puts the admin module in xxl-job-admin, the client library in xxl-job-core, sample executors in xxl-job-executor-samples, and container assets in docker/. The README points at the project home page for documentation, with separate Chinese and English documentation links, so the installation walkthrough lives there rather than in the README itself.

The README does not include an install snippet for the Maven dependency. What it does give is the artifact coordinate in the Maven Central badge, com.xuxueli:xxl-job-core, and the statement that the latest stable version is pushed to Maven Central for users to integrate. Pin the version that matches the admin you deploy.

The README also lists an official Docker image for the admin component as a containerization feature, published to Docker Hub and updated as part of that flow. The badge in the README names the image repository:

docker pull xuxueli/xxl-job-admin

After the admin is reachable, the workflow described in the feature list is: open the web console, create a job, choose a trigger strategy (cron, fixed interval, fixed delay, API event, manual, or parent-child), point it at an executor, and save. Changes to job state and parameters take effect immediately, and the console supports starting, stopping and terminating a running job. The executor samples directory is the reference for how a handler is registered on the client side.

One detail worth checking before you start: the admin module stores its state in a database, and the related searches around PostgreSQL suggest people do run it on engines other than the default. Confirm the schema scripts in the repository match your database before you point the admin at it.

GLUE, script handlers and the AI executor

GLUE is the feature that separates XXL-JOB from a plain cron wrapper. It provides a web IDE where the job body is written and published online, compiled and effective without a deploy cycle, and the README states it keeps 30 historical versions for rollback. Script tasks in GLUE mode cover Shell, Python, NodeJS, PHP and PowerShell, which is the practical answer for teams whose jobs are not Java. There is also a generic command-line handler, CommandJobHandler, where the business side only supplies the command string.

Version 3.4.x adds an AI executor with built-in AI task handlers, and the README names integrations with spring-ai, ollama, openclaw and dify. Treat that as an execution surface, not a shift in what the product is: the scheduler still decides when and where a handler runs, and the handler happens to call a model. The README also lists an audit log for sensitive job operations, and graceful shutdown behaviour on both sides, where the admin waits for the time wheel to drain and an executor stops accepting new work while running tasks finish.

Where XXL-JOB is the wrong choice

The scheduling model is task-centric. A job is a unit with a trigger, a routing policy and a handler. Dependencies exist through child jobs, configured as a comma-separated list that fires after a parent completes successfully. That is not the same as a dataflow graph with typed inputs and outputs, and teams that need that shape will fight the model.

The database is a hard dependency for the admin, and consistency across an admin cluster is enforced through a database lock. That is a simple design, but it means the admin's availability is tied to the database's. The README does not document what happens to in-flight triggers when that database becomes unavailable, and it does not document rollback of a job definition beyond GLUE's version history for code.

Language support deserves a blunt reading. Java is the native path. Python, Go and other languages are served through the RESTful OpenAPI, the multi-task mode, or httpJobHandler, all of which the README lists as cross-language options. That works, but you are implementing the executor contract yourself, and you inherit the versioning problem of keeping a hand-written client in step with the admin. Finally, the licence is GPL-3.0. If you embed the admin or core in something you distribute, that is a decision for your own legal review, not something the README resolves.

XXL-JOB versus Quartz, Airflow and PowerJob

Quartz is a Java scheduling library that runs inside your application. It gives you triggers and job stores, but it does not give you a separate admin console, a registry of remote executors, or a routing layer across a cluster. XXL-JOB puts the scheduler outside the application and makes the executor a registered participant, which is the difference between a library and a platform. If you only need in-process timers, Quartz is less machinery.

Airflow is a workflow orchestrator built around DAGs and Python. Its unit of work is a task in a graph with data dependencies; XXL-JOB's unit is a job with a trigger and a handler. If your problem is a pipeline with upstream and downstream data contracts, the DAG model is a better fit, and XXL-JOB's parent-child job list will feel thin.

PowerJob is the closest comparison in the Java scheduling space, and it appears in the search data as a direct alternative. The README does not describe PowerJob's internals, so the honest difference to state is this: both are distributed Java schedulers with an admin and workers, and the choice comes down to which one's execution model, console and operational story you can run. Evaluate them against the same job, not against feature lists.

Maintenance, upgrade cost and the GPL-3.0 question

The repository is not archived, and the last push was on 2026-07-21. Releases in 2026 include 3.4.0 on 2026-04-05, 3.4.1 on 2026-06-14 and 3.4.2 on 2026-06-19. That is a recent, active release line, but it also means the 3.4.x series moved quickly within a few months, so pinning a version and reading the release notes before jumping is cheaper than tracking master.

Upgrade cost concentrates in two places. The admin carries its own database schema, and the executor client is a separate artifact, so admin and client versions need to be kept compatible. The repository keeps xxl-job-executor-samples in tree, which is the reference for what a supported client looks like at a given version. GLUE jobs are stored in the admin, so their version history travels with the admin's database rather than with your source control, and that is a migration consideration when you move environments.

The licence is GPL-3.0, per the repository's LICENSE file and the README badge. GPL-3.0 is a copyleft licence; the practical consequence for a team embedding the admin or core into distributed software is a question for your own legal review. The README does not offer an alternative licence or a commercial exception.

Editorial conclusion

Adopt XXL-JOB when your scheduled work is already Java-centric, cron-shaped and needs a shared console with retries, sharding and alerting; the admin and executor split is the whole point. Do not adopt it if you need a Python or Go job body to run natively, or if you want a DAG-first data pipeline tool, because the scheduling model here is task-centric rather than dataflow-centric. Before committing, verify three things against your own deployment: that your database is one the admin module supports, that the executor version you pin matches the admin version, and that GPL-3.0 is acceptable for how you distribute the software. The last push to master was on 2026-07-21, so check the release page rather than assuming a cadence.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xuxueli/xxl-job on GitHub