Hi, Currently Mesos membership scheme relies on Marathon REST API to discover the members in a cluster. There can be situations where access to Marathon REST API could be restricted and access cannot be granted for Carbon products due to security concerns.
However, we can still discover members in the cluster by using Mesos DNS REST API [1]. I've implemented this functionality in [2]. We can set the DNS endpoint via MESOS_DNS_ENDPOINT parameter in axis2.xml. We can change the member discovery scheme by defining the MESOS_MEMBER_DISCOVERY_SCHEME parameter in axis2.xml. The default will be 'Marathon' (via Marathon REST API). It is important to understand that Mesos DNS will periodically query the master node to get a list of members, therefore it is possible that there will be a delay to reflect the latest state. I've introduced a DNS update timeout (DNS_UPDATE_TIMEOUT which defaults to 10s), period of time to keep retrying if the service is not found. Note that if there are shared Marathon applications when creating a single Hazelcast cluster you need to include them in MARATHON_APPLICATIONS parameter as comma separated values. For eg: WSO2 ESB worker/manager setup wso2esb manager should not have any value for MARATHON_APPLICATIONS since it should be started first, before the worker. Members in the same application (wso2esb-manager in this case) will be added by default wso2esb worker should have "wso2esb-manager" as MARATHON_APPLICATIONS since it will be started after the manager. [1] https://mesosphere.github.io/mesos-dns/docs/http.html [2] https://github.com/wso2/mesos-artifacts/tree/master/common/mesos-membership-scheme Thanks. -- Akila Ravihansa Perera WSO2 Inc.; http://wso2.com/ Blog: http://ravihansa3000.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
