This repository contains a plugin which provides the automatic Hazelcast member discovery using Eureka Service Registry.
NOTE: hazelcast-eureka-two 3.x is compatible with Eureka 2.x and Hazelcast 5.x, for older hazelcast versions you need to use eureka-one branch.
To use Hazelcast embedded in your application, you need to add the plugin dependency into your Maven/Gradle file. Then, when you provide hazelcast.xml
(and hazelcast-client.properties
) as presented below, your Hazelcast instances will use Eureka Server to discover each other automatically.
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-eureka-two</artifactId>
<version>${hazelcast-eureka-version}</version>
</dependency>
compile group: "com.hazelcast", name: "hazelcast-eureka-two", version: "${hazelcast-eureka-version}"
Make sure you have:
hazelcast-eureka-two.jar
in your classpath- Hazelcast configuration (
hazelcast.xml
or Java-based configuration) - Eureka client configuration (
eureka-client.properties
file oreureka.client.props
dynamic property in the Hazelcast configuration)
<hazelcast>
<network>
<join>
<multicast enabled="false"/>
<eureka enabled="true">
<self-registration>true</self-registration>
<namespace>hazelcast</namespace>
</eureka>
</join>
</network>
</hazelcast>
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getEurekaConfig().setEnabled(true)
.setProperty("self-registration", "true")
.setProperty("namespace", "hazelcast");
The following properties can be configured:
self-registration
: Defines if the Discovery SPI plugin will register itself with the Eureka 1 service discovery. It is optional. Default value istrue
.namespace
: Definition for providing different namespaces in order not to collide with other service registry clients in eureka-client.properties file. It is optional. Default value ishazelcast
.use-metadata-for-host-and-port
: Defines if the Discovery SPI plugin will use Eureka metadata map to store host and port of Hazelcast instance, and when it looks for other nodes it will use the metadata as well. Default value isfalse
.skip-eureka-registration-verification
: When first node starts, it takes some time to do self-registration with Eureka Server. Until Eureka data is updated it make no sense to verify registration. See Time Lag. This option will speed up startup when starting first cluster node. Default value isfalse
.
Below you can also find an example of eureka-client.properties
.
hazelcast.shouldUseDns=false
hazelcast.name=hazelcast-test
hazelcast.serviceUrl.default=http://<your-eureka-server-url>
Note: hazelcast.name
property is crucial for cluster members to discover each other. Please give the identical names in regarding eureka-client.properties
on each Hazelcast member.
In some environments adding the eureka-client.properties
file to the classpath is not desirable or feasible. To support this use case, it is possible to specify the Eureka client properties in the Hazelcast configuration. Set the use-classpath-eureka-client-props
property to false
, then add the Eureka client properties without prepending the namespace, as they will be applied to the namespace specified with the namespace
property.
NOTE: If use-classpath-eureka-client-props
is true
(its default value), all Eureka client properties in the Hazelcast configuration will be ignored.
The following is an example declarative configuration, equivalent to the example given above.
<hazelcast>
<network>
<join>
<multicast enabled="false"/>
<eureka enabled="true">
<self-registration>true</self-registration>
<namespace>hazelcast</namespace>
<use-classpath-eureka-client-props>false</use-classpath-eureka-client-props>
<shouldUseDns>false</shouldUseDns>
<name>hazelcast-test</name>
<serviceUrl.default>http://your-eureka-server-url</serviceUrl.default>
</eureka>
</join>
</network>
</hazelcast>
Configuring Hazelcast Client follows exactly the same steps as configuring Hazelcast member, so you need to have:
hazelcast-eureka-two.jar
in your classpath- Hazelcast client configuration (
hazelcast-client.xml
or Java-based configuration) - Eureka client configuration (
eureka-client.properties
file oreureka.client.props
dynamic property in the Hazelcast configuration)
Following are example declarative and programmatic configuration snippets.
<hazelcast-client>
<network>
<eureka enabled="true">
<namespace>hazelcast</namespace>
</eureka>
</network>
</hazelcast-client>
clientConfig.getEurekaConfig().setEnabled(true)
.setProperty("namespace", "hazelcast");
Note: Hazelcast clients do not register themselves to Eureka server, therefore self-registration
property has no effect.
Note: The eureka-client.properties
file and the eureka.client.props
dynamic property mechanism work exactly the same as described in the Hazelcast Member Configuration.
If your application already provides a configured EurekaClient
instance e.g. if you are using Spring Cloud, you can reuse your existing client:
EurekaClient eurekaClient = ...
EurekaOneDiscoveryStrategyFactory.setEurekaClient(eurekaClient);
EurekaOneDiscoveryStrategyFactory.setGroupName("dev"); // optional group name. Default is 'dev'.
Note that if you have Hazelcast embedded in your application and you want to use Eureka Service discovery for both the application itself and Hazelcast, by default they collide. You can solve this issue in one of the following manners:
- use a separate
EurekaClient
for the application and a separateEurekaClient
for Hazelcast - use the same
EurekaClient
, but setuse-metadata-for-host-and-port
property totrue
(it makes Hazelcast store its host/port in the Metadata for your Eureka application).
Please note that If you use metadata to store cluster member addresses on Eureka application "hazelcast" then the discovery plugin will only find the host and port stored in the metadata for that app, not for any other Eureka app.
In case of any question or issue, please raise a GH issue or contact as directly via Hazelcast Community Slack.