[jira] Issue Comment Edited: (CASSANDRA-2019) add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)

["Yang Yang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984320#action_12984320 ] 

Yang Yang edited comment on CASSANDRA-2019 at 1/20/11 2:14 PM:
---------------------------------------------------------------

Thanks a lot Jonathan. 

I'll refactor my code according to the seedsFinder interface.


for the tokens setting thing,  what we are doing is that we extend thrift.CassandraDaemon, and do the custom tricks to figure out the token first thing in that daemon, and then we call DatabaseDescriptor.setToken() ,  finally we start the original thrift.CassandraDaemon. 

we also do other custom work at this stage, for example setting up the JMX notification listener for the SSTable notifications that we added in another jira.


I just looked at CASSANDRA-957  ,  here are my 2cents:  the  token assignment problem is roughly similar to membership control. it's a fairly complex problem and there are existing solutions. so it may be better to abstract out that piece and put it in a module. for example, you could store the 
host--->token mapping in a central store:SimpleDB, ZooKeeper, or even the simplest , just in local storage. this membership control should be hooked up with monitoring in order to achieve automatic host fail-over and token re-assignment.   for example in our case, we query EC2 autoscaler to purge a dead host (that is already not part of ASG) from its claim on a token.    so leaving out the smart decision out, and only keep an interface setInitialToken() to receive such decision might be more flexible for  different kinds of token assignment schemes.  ---- this is kind of similar to the approach that you have taken on the SeedsFinder  interface

Thanks a lot 
Yang

      was (Author: yangyangyyy):
    Thanks a lot Jonathan. 

I'll refactor my code according to the seedsFinder interface.


for the tokens setting thing,  what we are doing is that we extend thrift.CassandraDaemon, and do the custom tricks to figure out the token first thing in that daemon, and then we call DatabaseDescriptor.setToken() ,  finally we start the original thrift.CassandraDaemon. 

we also do other custom work at this stage, for example setting up the JMX notification listener for the SSTable notifications that we added in another jira.


I just looked at CASSANDRA-957  ,  here are my 2cents:  the  token assignment problem is roughly similar to membership control. it's a fairly complex problem and there are existing solutions. so it may be better to abstract out that piece and put it in a module. for example, you could store the 
host--->token mapping in a central store:SimpleDB, ZooKeeper, or even the simplest , just in local storage. this membership control should be hooked up with monitoring in order to achieve automatic host fail-over and token re-assignment.   for example in our case, we query EC2 autoscaler to purge a dead host (that is already not part of ASG) from its claim on a token.    so leaving out the smart decision out, and only leave an interface setInitialToken() to receive such decision might be more flexible for  different kinds of token assignment schemes.  ---- this is kind of similar to the approach that you have taken on the SeedsFinder  interface

Thanks a lot 
Yang
  
> add interface to DatabaseDescriptor to help setting seeds and tokens at boot time (for EC2 feature)
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-2019
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2019
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Yang Yang
>             Fix For: 0.7.1
>
>         Attachments: DBdscrpt.diff
>
>
> 1)
> in the amazon EC2 environment, machines die off and more frequently, and new instances are brought up more often, so even if we list out all the nodes in the ring as seeds, all of these seeds may have gradually died off after some time. at that time , new nodes joining won't be able to find the existing ring, and will establish a new, separate ring of the same name, which is wrong. 
> we have made some custom code that utilizes external systems to figure out the EC2 autoscaler group, and at boot time feed this info to the new node. but this requires the new node to be able to modify the seeds at boot time. right now the DatabaseDescriptor only has a getSeeds() method, we would like to add a setSeeds()
> 2) similarly, for the token-1  trick, we wrote code to do this automatically.  the StorageService.initServer() code reads the initialToken at boot time, we need to be able to modify this  at boot time. so we would like to add DatabaseDescriptor.setInitialToken()
> patch attached. 
> also theoretically we could do both just by modifying the config file, but that requires running a separate process before cassandra daemon starts, which is not as clean.
> Thanks a lot 
> Yang

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.