Understanding Eureka Server Registration Process: A Source Code Walkthrough

The author introduces the fourth article in a series about the Eureka registration center, focusing on the server‑side registration flow from a source‑code perspective and pointing out valuable design patterns such as the data structure used for the registry and the read‑write lock for concurrency.

1. Registration Entry

The server receives registration HTTP requests via a Jersey servlet. The relevant configuration can be found in the \eureka\eureka-server\src\main\webapp\WEB-INF\web.xml file, and the request handling classes reside under \eureka\eureka-core\src\main\java\com\netflix\eureka\resources . The ApplicationsResource class’s addInstance method processes the registration.

2. Receiving the Registration Request

The core call inside addInstance is:

registry.register(info, true);

Here registry is an instance of PeerAwareInstanceRegistryImpl , which implements the PeerAwareInstanceRegistry interface. The call eventually reaches the abstract AbstractInstanceRegistry implementation of register() , which stores the instance information.

3. Storing Registration Information

The registry keeps data in a ConcurrentHashMap<String, Lease<InstanceInfo>> named gNewMap , assigned to gMap . The map’s key is a unique instance ID (e.g., i-00000004 ) and the value is a Lease object that holds the InstanceInfo (IP, port, etc.). Storing a new instance is as simple as:

gMap.put(registrant.getId(), lease);

The article shows a screenshot of the map after registering two instances.

4. Notable Design Choices

4.1 Why ConcurrentHashMap? Unlike HashMap , which can cause deadlocks or data loss under concurrency, ConcurrentHashMap partitions the map into segments (default 16) so that only the relevant segment is locked during a put , allowing true parallelism for non‑conflicting updates.

4.2 Read‑Write Lock The source uses ReentrantReadWriteLock to allow multiple concurrent reads while writes obtain exclusive access:

readWriteLock = new ReentrantReadWriteLock();
Lock read = readWriteLock.readLock();
read.lock();
... // read operations
read.unlock();

This improves efficiency because registration reads can proceed in parallel, while writes are serialized to maintain consistency.

5. Conclusion

The article demonstrates that Eureka stores registration data in a ConcurrentHashMap and controls concurrent modifications with a read‑write lock, while Jersey handles the incoming HTTP registration requests. Readers can apply these patterns to their own projects and reinforce their understanding of Java concurrency primitives.