Skip to content

Delayed Messages Delivered Early or Late (Clock Skew) ​

Updated: 10/15/26, 10:20:22 AM

Symptom ​

A delayed message set to 10 seconds is consumed after about 6; or one set to 5 seconds arrives only after 8.

Cause ​

Artemis delayed messages are delivered by absolute timestamp — the sender computes "current time + delay" with its local clock and writes it into the message properties, and the broker waits until its own clock reaches that timestamp to deliver. When the app and the broker are deployed on different machines with inconsistent clocks, the actual delay shifts by the clock difference:

  • App machine clock behind the broker → messages are delivered early (here it was about 4 s behind, so a 10-second delay landed in about 6)
  • App machine clock ahead of the broker → messages are delivered late

Diagnosis ​

Compare the two machines' clocks. You can compare the Date response header of any HTTP service on the broker host (e.g. the Artemis console on port 8161) against your local time:

bash
curl -sI http://<broker-host>:8161/ | grep -i '^date'   # broker-side time (second-level precision)
date                                                    # local time

Fix ​

Enable NTP time sync on both machines.

Linux server (the broker host):

bash
timedatectl                          # check the "System clock synchronized" and "NTP service" status
sudo timedatectl set-ntp true        # enable timesyncd first if it is not enabled
# If the system has no timesyncd, install chrony to take over (use dnf on RHEL; the service is named chronyd):
sudo apt install chrony && sudo systemctl enable --now chrony
chronyc tracking                     # verify: Leap status "Normal" means synced

Windows dev machine (running the backend locally against a remote broker):

powershell
w32tm /query /status                 # check the time-service status and the last successful sync time
# The next two commands require an elevated terminal:
w32tm /resync                        # resync immediately (the clock drifts after sleep/resume; run manually if needed)
w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.aliyun.com time.windows.com" /update
                                     # switch to China-based NTP sources when time.windows.com is unreliable

TIP

In official-installer deployments, the app and Artemis are containers on the same host sharing the kernel clock, so this problem cannot occur there. It typically appears in "local backend + remote broker" development topologies and in self-managed cross-machine broker deployments — for cross-machine deployment, NTP alignment is a hard prerequisite for delayed-message accuracy.


Back to FAQ