feat: add dynamic config hot-reload using JDK WatchService

[SPUERSAIYAN]

[Enhancement] Use JDK WatchService in ConfigMonitorService to Monitor Config Changes

Fixes #3331

Motivation

The original ConfigMonitorService used a scheduled polling mechanism to detect configuration file changes every 30 seconds. This approach had the following drawbacks:

1. High latency: after a configuration file was changed, it could take up to 30 seconds before the change was detected.

2. Unnecessary resource usage: the scheduled task kept running periodically even when no configuration file had changed.

Modifications

Core Changes

This PR changes the configuration monitoring mechanism from a polling-based model to an event-driven model.

Item | Original Implementation | New Implementation -- | -- | -- Monitoring mechanism | ScheduledExecutorService polling every 30 seconds | JDK WatchService event-driven monitoring Data structures | ArrayList | ConcurrentHashMap + CopyOnWriteArrayList Response latency | Up to 30 seconds | Near real-time Resource usage | Periodic polling regardless of changes | Triggered only when file system events occur

New Files

• WatchFileManager.java: manages file monitoring by using JDK WatchService to monitor directories.

• FileChangeListener.java: defines the listener interface for file change events.

• FileChangeContext.java: provides context information for file change events.

Changes in ConfigMonitorService.java

• Removed the ScheduledExecutorService based polling mechanism.

• Removed the TIME_INTERVAL constant.

• Added a ConcurrentHashMap to store mappings between configuration file paths and listeners.

• Registered file change listeners through WatchFileManager.registerFileChangeListener().

• Implemented FileChangeListener to handle configuration reload callbacks.

Solution

1. Replace Polling with Event-Driven Monitoring

The new implementation uses JDK WatchService to listen for file system events.

// Use JDK WatchService to monitor file system events.
WatchFileManager.registerFileChangeListener(directoryPath, CONFIG_FILE_CHANGE_LISTENER);

This relies on the underlying operating system’s file notification mechanism, avoiding unnecessary periodic polling.

2. Match the Changed File Path

ConfigMonitorService implements FileChangeListener and only handles changes for registered configuration files.

// Only handle monitored configuration files.
List<ConfigInfo> configInfoList = CONFIG_INFO_MAP.get(changedFilePath);
if (configInfoList != null) {
    for (ConfigInfo configInfo : configInfoList) {
        load(configInfo);
    }
}

3. Improve Resource Management

All monitoring resources are cleaned up automatically when the JVM exits.

// Automatically clean up resources when the JVM shuts down.
static {
    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        log.info("[ConfigMonitorService] shutdown, clearing {} entries", CONFIG_INFO_MAP.size());
        CONFIG_INFO_MAP.clear();
    }));
}

Benefits

• Configuration changes can be detected in near real time.

• Periodic polling is removed, reducing unnecessary resource consumption.

• The new implementation is more scalable when multiple configuration files are monitored.

• Thread-safe data structures are used to improve concurrent access safety.

[github-actions]

Welcome to the Apache EventMesh community!!
This is your first PR in our project. We're very excited to have you onboard contributing. Your contributions are greatly appreciated!

Please make sure that the changes are covered by tests.
We will be here shortly.
Let us know if you need any help!

Want to get closer to the community?

WeChat Assistant	WeChat Public Account	Slack
		Join Slack Chat

Mailing Lists:

Name	Description	Subscribe	Unsubscribe	Archive
Users	User support and questions mailing list	Subscribe	Unsubscribe	Mail Archives
Development	Development related discussions	Subscribe	Unsubscribe	Mail Archives
Commits	All commits to repositories	Subscribe	Unsubscribe	Mail Archives
Issues	Issues or PRs comments and reviews	Subscribe	Unsubscribe	Mail Archives

[Pil0tXia]

I'll review it later.

[github-actions]

It has been 60 days since the last activity on this pull request. I am reaching out here to gently remind you that the Apache EventMesh community values every pull request, and please feel free to get in touch with the reviewers at any time. They are available to assist you in advancing the progress of your pull request and offering the latest feedback.

If you encounter any challenges during development, seeking support within the community is encouraged. We sincerely appreciate your contributions to Apache EventMesh.