Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sagar Raut
    @v8sagar
    hi all if set this config, and same code deployed on two different AWS instance
    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");
    Hazelcast
    @hazelcast_twitter
    [Rafal Leszko (unknown)] Yes, it looks correct assuming you have tags configured on your EC2 Instances and the port 5701 is open in security groups
    Sagar Raut
    @v8sagar
    Just to rephrase
    same configs code have deployed on both the servers I mean api-1 and api-2
    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");
    above code is constant
    Hazelcast
    @hazelcast_twitter
    [Rafal Leszko (unknown)] yes, it's fine
    Jaromir Hamala
    @jerrinot
    @Vignesh-Thiraviam the clustered API in Managmeent Centre is all-or-nothing. It does not allow fine grained per-resource configuration for now.
    the new Management Centre for Hazelcast 4 has a Prometheus exporter and you will be able to define what to export.
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    Thank you very much @jerrinot . I will try to upgrade the version and use prometheus
    Jaromir Hamala
    @jerrinot
    you are very welcome. please report back your results!
    Jaromir Hamala
    @jerrinot

    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:

    1. If you use the client - server topology: Are you using User Code Deployment or ship JAR manually?
    2. If you use the embedded topology: Why? What are you reasons?

    I will be grateful for any feedback, thank you!

    Enes Ozcan
    @enozcan

    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

    Serdar Ozmen
    @Serdaro
    Hello everyone,
    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/#
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    hazelcast joins with different port rather than one specified in member configuration
    it joins with 5702 instead of 5701 , can anyone help on this
    Hazelcast
    @hazelcast_twitter
    [Sharath Sahadevan (Sharath Sahadevan)] Hi Vignesh - Typically I see this if the specified port is not available and auto-increment is on. Resolution is to free up that port and restart the process. If that does not work , Are you seeing any error messages in your logs? Also please provide your member config and info on the environment you are running in. Thanks!
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    hi , yes sure , I am running this in an open shift environment
    network:
    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"
    this is my member config
    10.173.14.23:5701 instead of this it is connecting to 10.173.14.23:5702
    hazelcast is present in 10.173.14.23:5702 also , so i am not getting any errors
    @ssahadevan
    lprimak
    @lprimak
    @jerrinot That's the problem I came across with Payara. If the application is not deployed on all nodes in the cluster, the cluster stopped working.
    in my implementation of Tenant Control, I just have to stop all processing indefinitely until application becomes available on all nodes in the cluster. Not the "ultimate" solution but it works since the use case is most likely rolling upgrades.
    It would be nice if migration can take into account application availability, but I think that's too ingrained in the design and would be too difficult to do
    well, not all processing, just the processing that has a partition on a node that doesn't have the application available
    jevgenija
    @jpantiuchina

    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.

    Jaromir Hamala
    @jerrinot
    @lprimak
    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?
    so you could demote a full member to a light member before stopping an app
    lprimak
    @lprimak
    I tried that, but it brings in a lot of other challenges, for example, managing that it's the "only" lite member then the cluster data loss would occur.
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    hi @ssahadevan , thanks a lot for information
    but in our application , our microservice is only sitting in kubernetes , hazelcast is sitting outside of it , so only we want to use TCP-IP mechanism
    Jaromir Hamala
    @jerrinot
    @Vignesh-Thiraviam can you share logs from all your Hazelcast cluster members?
    just to avoid any confusion: 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.
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    ok thanks @jerrinot , even if we specify port number , it will still look for others ?
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    just to confirm even if we specify 10.173.14.23:5701 , it will still look for other ports ? @jerrinot , because we are observing the same
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    Also is there a way to specify the port @jerrinot , kindly help on this :)
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    port:
      auto-increment: true
    is this the one you are telling @jerrinot , should we turn off this ?
    Jaromir Hamala
    @jerrinot
    if you change this to false then it will try to bind to the specified port only. when this port is unavaialbe (=already occupied) then Hazelcast will fail to start
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    ok thanks @jerrinot , by default this is true ?
    Jaromir Hamala
    @jerrinot
    yes, it is true by default
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    network:
    port:
    auto-increment: false
    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"
    is this now ok @jerrinot , will this work properly ?
    Jaromir Hamala
    @jerrinot
    so with this configuration it will:
    1. try to bind to a port 5701. when this port is unavailable then Hazelcast is will to start.
    2. if the port is available then the member starts. it will start looking for other cluster members and specified addresses. there are 2 options:
      2a. It will find an already running cluster on one of the configured addresses. then it will try to join the cluster. if the join is successful then it'll receive a list of other members running in the already existing cluster. important: the list it will receive from the existing cluster is not necessary the same as the addresses you configured.
      2b. it wont find any cluster running on either of the addresses. in this case the member will form its own cluster and it will start periodically checking the "10.173.14.23:5701,10.173.14.24:5701,10.173.14.25:5701,10.173.14.26:5701" and if eventually finds a cluster running there then it will try to join it. (if some other conditions are fulfilled)
    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    thanks a lot @jerrinot , so I will need to make sure that , all other members specified , doesn't have a different cluster to join . I will test this fix . Thank you
    Jaromir Hamala
    @jerrinot

    exactly. Othewise you can get surprising results.

    Consider this: You have 3 members: Member0, Member1, Member2

    Member0 has this configuration:

    hazelcast:
      network:
        join:
          multicast:
            enabled: false
          tcp-ip:
            enabled: true
            members: "Member0:5701, Member1:5701"

    Member1 has this configuration:

    hazelcast:
      network:
        join:
          multicast:
            enabled: false
          tcp-ip:
            enabled: true
            members: "Member0:5701, Member1:5701"

    Member2 has this configuration:

    hazelcast:
      network:
        join:
          multicast:
            enabled: false
          tcp-ip:
            enabled: true
            members: "Member0:5701"

    You start only Member0 and Member1. They have each other addresses in configuration so they discover each other and will form a cluster.

    Then you start Member2. It has only Member0 in its configuration, initially it knows nothing about Member1. So Member2 will discover an existing cluster running on Member0:5701 and will join this cluster. On joining it receives a list of all current cluster member. This list will contain also Member1:5701 so eventually Member2 will connect to Member1:5701 even it does not have its address in a configuration at all.

    I hope it makes some sense to you:)

    Vignesh-Thiraviam
    @Vignesh-Thiraviam
    thanks a lot , so I willtry this configuration port:
    auto-increment: false