ok. in this case you need to provide details about your environment and topology. clearly setPublicAddress("0.0.0.0") is wrong.
the question is: what should be there instead? (if anything at all)
here is what I know so far:
- you have 2 Hazelcast instances running on 1 server
- there is another instance running on a different service.
- all instances are in the same network
- all 3 instances are supposed to form a single cluster
is :point_up: correct?
setPublicAddress() sets an IP address others should use to talk to this member. this is usually needed when you have multiple networks and what not.for some reason you have
0.0.0.0 which CANNOT ever be used to talk to this member. The address 0.0.0.0 has a special meaning in IP networks.
- use multicast discovery. this is the default. it's simple to use and has no external dependency. but it does not work on most cluster providers as clouds do not allow multicast traffic.
- use static configuration. then you have to know IP address of all your members. I see you use
join.getTcpIpConfig().setEnabled(true).setMembers(Arrays.asList(environment));for this joiner you have to know all IP addresses anyway. - use a discovery plugin. this is the most popular option when deploying in clouds. we have discovery plugins for AWS, Azure, GCP, Kubernetes, Zookeepr, Eureka, etc..
setPublicAddress("127.0.0.1") will work only on a single box. again, remove that. most likely you dont need at all.
for my case, this will work perfectly fine right?
Config config = new Config();
config.setLiteMember(false);
JoinConfig join = config.getNetworkConfig().getJoin();
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
.setProperty("tag-key", "my-ec2-instance-tag-key")
.setProperty("tag-value", "my-ec2-instance-tag-value");
CacheSimpleConfig cacheConfig = new CacheSimpleConfig();
cacheConfig.setName("buckets");
config.addCacheConfig(cacheConfig);
HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance(config);
ICacheManager cacheManager = hazelcastInstance.getCacheManager();
Cache<String, GridBucketState> cache = cacheManager.getCache("buckets");
return cache;2>there is another instance running on a different service.
3>all instances are in the same network
4>all 3 instances are supposed to form a single cluster
that looks fine to me.
some notes: config.setLiteMember(false); is redundant as that's the default.
depending on your deployment scheme you might want to store hazelcastInstance somewhere and shut it down when your application is about to shutdown. this is mostly concern if you deploy to an app server with multiple tenants (applications). If you are using something like Spring Boot (or appserver-less deployment in general) then it's usually not a concern.
if my all three instances are now same network
will this work
Config config = new Config();
config.setLiteMember(false);
System.out.println( Arrays.asList(environment).toString());
JoinConfig join = config.getNetworkConfig().getJoin();
join.getMulticastConfig().setEnabled(false);
join.getAwsConfig().setEnabled(false);
join.getTcpIpConfig().setEnabled(true).setMembers(Arrays.asList("172.323.24.130","896.341.438.65"));
api-1 and api-2 both are talking to each other will this work
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
.setProperty("tag-key", "Name1")
.setProperty("tag-value", " api-1")
.setProperty("access-key","1")
.setProperty("secret-key","1");
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
.setProperty("tag-key", "Name2")
.setProperty("tag-value", " api-2")
.setProperty("access-key","2")
.setProperty("secret-key","2");config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
.setProperty("tag-key", "Name1")
.setProperty("tag-value", " api-1")
.setProperty("access-key","1")
.setProperty("secret-key","1");
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
.setProperty("tag-key", "Name2")
.setProperty("tag-value", " api-2")
.setProperty("access-key","2")
.setProperty("secret-key","2");Hello everyone,
I am from Hazelcast development team and I am trying to learn more about How People Use Hazelcast.
One of the Hazelcast painpoints is reliance on Java bytecode.
Example: IMap Entry Processors are awesome, they can often replace a complicated locking schema, increase both reliability and performance.
However they have one downside: They require bytecode to be available on each member classpath. This is usually not a issue if you are embedding Hazelcast inside your application. But It could be a problem in the client-server topology when your app uses a remote cluster. In this case you have to either distribute JARs with Entry Processors to all cluster members or use User Code Deployment.
I have 2 different questions is:
- If you use the client - server topology: Are you using User Code Deployment or ship JAR manually?
- If you use the embedded topology: Why? What are you reasons?
I will be grateful for any feedback, thank you!
Hi everyone,
We just introduced Hazelcast Guides with ~10 min. guides on Hazelcast integrations with Springboot, Quarkus, Micronaut, Microprofile, Kubernetes, Istio, and more! Check it out at https://guides.hazelcast.org
In addition to the brilliantly prepared guides mentioned above, also please don’t forget to check out our latest development Hazelcast IMDG Reference Manual updated and uploaded daily: https://docs.hazelcast.org/docs/latest-dev/manual/html-single/#
join:
multicast:
enabled: false
tcp-ip:
enabled: true
members: "10.173.14.23:5701,10.173.14.24:5701,10.173.14.25:5701,10.173.14.26:5701"