Hi Kishore,

Thanks for the answers.

My understanding is that Helix with SEMI AUTO mode won't change shard
mapping autotically, but may change the roles of each replica. Please
correct me if this is wrong.
I am wondering how will SEMI AUTO Helix change the roles of replicas
mastered on a participant whose ZK session is just expired? Ideally, we
want to first 1) change the role of master replicas on the expired
participant to Slave, and then 2) promote some other live participant to be
the new Masters for those partitions.
For 1), we can add some timer logic at the participant side to
automatically (without receiving requests from the Controller, because it
can't talk to ZK to receive Controller requests) change their roles to be
Slave if its ZK session is expired. For 2), Controller needs to change all
relevant data stored on ZK to indicate that all replicas on the expired
participant are Slaves, and then request some live participants to be the
new Master and change the ZK data to indicate new Masters. My understanding
is that Helix Controller always sends msg to participants to change their
states and then update ZK data when responses are received from
participants. This doesn't apply to an expired/dead participant. Because a
dead participant can't act on a state change request.
Please let me know if I missed anything and Helix has a straightforward way
to solve it.

On Tue, Jan 2, 2018 at 12:49 PM, kishore g <[EMAIL PROTECTED]> wrote:
Best regards,
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB