Understanding Nacos Configuration Center Long‑Polling Mechanism: Client and Server Implementation

The article introduces Nacos as a service‑discovery and configuration platform and focuses on one of its core features: the long‑polling mechanism used by the configuration center.

1. Client‑side Long‑Polling

The process starts from NacosPropertySourceLocator.locate() , which creates a ConfigService instance via NacosFactory.createConfigService() :

public static ConfigService createConfigService(Properties properties) throws NacosException {
    // create ConfigService
    return ConfigFactory.createConfigService(properties);
}

During construction of NacosConfigService , a ClientWorker is instantiated. The worker creates two scheduled thread pools and launches a periodic task that runs every 10 seconds to check for configuration changes.

The main logic resides in LongPollingRunnable.run() , which iterates over cached configuration data, calls checkLocalConfig() to detect local changes, and invokes checkUpdateDataIds() to query the server for updates:

public void run() {
    List
cacheDatas = new ArrayList();
    // iterate cache, check local config
    // request server for updates via long‑polling
    // trigger listener notifications if needed
}

If a change is detected, the client fetches the new content using ClientWorker.getServerConfig() , which internally calls MetricsHttpAgent.httpGet() on the /v1/cs/configs endpoint and stores the snapshot locally.

2. Server‑side Long‑Polling

On the server, the ConfigController.listener() endpoint receives the long‑polling request. The request is processed by ConfigServletInner.doPollingConfig() , which delegates to LongPollingService.addLongPollingClient() . This method wraps the request into a ClientPolling object and schedules it with a 29.5‑second timeout.

The scheduled task executes ClientLongPolling.run() . If no configuration change occurs within the timeout, the server holds the connection; otherwise it returns the changed dataId , group , and tenant to the client.

3. Event Listening and Handling

When a configuration change is made on the Nacos server, a LocalDataChangeEvent is published. Earlier versions (≤1.3.1) handled this via LongPollingService.onEvent() ; newer versions (≥1.3.2) use a Subscriber.onEvent() implementation.

The event triggers a DataChangeTask.run() which retrieves the updated configuration and pushes it to the client through the long‑polling response.

4. Summary of Key Classes and Methods

NacosPropertySourceLocator.locate() – initializes ConfigService.

NacosConfigService.NacosConfigService() – constructor that starts the client worker.

ClientWorker.checkConfigInfo() – schedules periodic checks.

MetricsHttpAgent.httpPost() – sends long‑polling request to /v1/cs/configs/listener .

MetricsHttpAgent.httpGet() – fetches updated configuration from /v1/cs/configs .

ConfigController.listener() – server entry point for listener requests.

LongPollingService.addLongPollingClient() – core server‑side long‑polling handling.

DataChangeTask.run() – processes configuration change events.

Overall, the article dissects both client and server implementations of Nacos' long‑polling mechanism, providing code excerpts, flow diagrams, and explanations that help developers understand and debug configuration synchronization in microservice environments.