Understanding Nacos Configuration Center Long‑Polling Mechanism and Its Implementation

This article introduces one of the core principles of Nacos configuration center – the long‑polling mechanism – and demonstrates its practical usage with detailed code analysis.

The client side creates a ConfigService instance via NacosFactory.createConfigService() , which internally uses reflection to instantiate NacosConfigService . The constructor starts a scheduled task in ClientWorker that checks configuration changes every 10 seconds.

The long‑polling task ( LongPollingRunnable.run() ) iterates over cached configuration data, checks local files, and, if changes are detected, sends a request to the server using MetricsHttpAgent.httpPost() to the /v1/cs/configs/listener endpoint.

public static ConfigService createConfigService(Properties properties) throws NacosException {
    //【断点步入】创建 ConfigService
    return ConfigFactory.createConfigService(properties);
}

When the server reports changed DataId , Group , and Tenant , the client retrieves the new configuration via MetricsHttpAgent.httpGet() to /v1/cs/configs and updates the local cache.

On the server side, ConfigController.listener() receives the long‑polling request, delegating to ConfigServletInner.doPollingConfig() , which creates a ClientLongPolling task and registers it with LongPollingService.addLongPollingClient() . The service holds the request for up to 30 seconds, returning early only when a configuration change is detected.

Configuration change events are emitted as LocalDataChangeEvent and processed by DataChangeTask.run() through a thread pool, ensuring the updated data is sent back to the client.

The article concludes with a structural summary of the involved classes and methods, illustrating the end‑to‑end flow from client initialization to server‑side long‑polling handling.