I am working on a feature that would allow the leader/follower usage on acceptors.
An acceptor would be waiting for a lock, and it would start the acceptor when the lock is acquired, and stop when the lock is lost. I am working to add a few types of locks: - etcd - fileShared - JDBC I have a few questions on the implementation: i - is etcd useful on the openshift world? it seems that the PODs will not have access to etcd directly and an operator is supposed to prepare the lock in some indirect way. ETCD might still be useful for standalone, but perhaps this is not a good fit for the openshift world. ii - netty and vertx implementation. I am playing https://github.com/etcd-io/jetcd, and it is bring vertx and netty. Currently I had to revert back one version as the netty version is clashing with our current netty usage. What brings me to think.. is this the right approach since it will bring vertx and netty as external dependencies from the library. iii - Perhaps I should skip the etcd option for now and only support fileLock and JDBC. iv - how to configure this. I'm planning to add something like leadership in the XML <leadership> <leader lock-name="myLock" type="Type"> <!-- type being file, jdbc, or etcd (if we are still going for it) --> <properties> </properties> </leader> </leadership> and on either acceptor or server <server leader="myLock"> ... <acceptor leader="myLock"> the idea is that one leader choice could be able to start or stop multiple objects (in this case for now, server or acceptors).. you could have multiple acceptors towards the same leadership ellection. any feedback is appreciated. -- Clebert Suconic --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
