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"
Dear Hazelcast developers,
As part of a research team from Università della Svizzera italiana (Switzerland) and University of Sannio (Italy), we have analyzed refactoring pull requests in hazelcast/hazelcast repository and are looking for developers for a short 5-10 min survey (https://usi.eu.qualtrics.com/jfe/form/SV_cO6Ayah0D6q4eSF). Would you please spare your time by answering some questions about refactoring-related contributions? We would greatly appreciate your input — it would help us understand how developers can improve the quality of refactoring contributions, and benefit the development process. The responses will be anonymized and handled confidentially! Thank you a lot!
If you consider this message to be spam, I'm very sorry! There will be no follow-up to bother you.
thanks for sharing this. would a light member help with your use-case? a light member is a cluster member with no partitions assigned. right now you have to configure a light member upfront. you can promote a light member to a full blown member in runtime, but you cannot go the other way around. would that ability help you?
members: "10.173.14.23:5701,10.173.14.24:5701,10.173.14.25:5701,10.173.14.26:5701" says where to look for other members.It does not tell on what port this member should bind to. by default Hazelcast binds to 5701. If that port is unavailable it'll increment the port by 1 and will try again.