Scalecube based membership #48
Conversation
This is awesome, while the tests work locally it fails sometimes on SnapCI because of the default Gossip settings. The fact that gossip isn't as relaiable and consistent as Atomix is a proof that this works.
- Removed the Member case class, it was not serving any use whatsoever - Refactored both AtomixMembership + ScalecubeMembership for the new contract - Reduced the Gossip interval for tests to see if it helps during SnapCI Builds
… Needs more investigation
|
This is kinda sad, that Cluster doesn't seem to converge even after 60 seconds on SnapCI for Scalecube based membership. Not sure what's going wrong, and I'm not able to reproduce it locally either. For now I've disabled the IntegrationTest. Will look into it further. |
Current coverage is 74.22% (diff: 80.89%)
|
After learning about rxJava and scalecube more
|
Fixed the test issue for ScaleCube on SnapCI. |
TLDR; - Change contracts in Membership abstract class with scaladocs - Adding MemberListener - Bootstrapper -> SeedProvider - changed the names as it was confusing to use - Integrated the new Membership contract with Atomix + ScaleCube implementations + fixing the tests too MemberListener are pluggable event listeners to changes in membership. This allows us to write composable components like how should ConsistentHashRing react to new nodes or exit of an existing nodes in the cluster. Membership implementations should just plug `onJoin` and `onLeave` methods in Membership to the actual membership events in the cluster. Membership would take care of calling all the event listeners in order with MemberAddress of the node that has the respective event.
… be just generated code + samples Enable it back if you feel we're writing more code in it which isn't generated
Cluster brings the notion of a distributed system much more than Membership. Also update the module names to have cluster, suuchi-membership-* -> suuchi-clustre-*
|
Timing of this Tweet! Wow! https://twitter.com/kellabyte/status/784952690946080768
|
ClusterProvider uses ServiceLoader to load the actual implementation at runtime. This way we can keep the implementations outside and just provide stubs in the suuchi-core module.
Conflicts: suuchi-core/src/main/scala/in/ashwanthkumar/suuchi/rpc/Server.scala
|
@brewkode I think we should merge this branch of take some features like extracting atomix out of the core and move back to JDK7, since most of our internal infra is still on JDK7. Especially the MR cluster. |
Conflicts: suuchi-core/src/main/scala/in/ashwanthkumar/suuchi/partitioner/PartitionNode.scala
|
We might need a config file based Membership provider in the core. |
| </parent> | ||
|
|
||
| <properties> | ||
| <log4j.version>2.6.2</log4j.version> |
| </parent> | ||
|
|
||
| <properties> | ||
| <log4j.version>2.6.2</log4j.version> |
There was a problem hiding this comment.
Similarly do we need this in here?
|
Merging this in. Will continue to work on the feedback through another PR. |
Extracting membership implementations as a separate library. I just stumbled upon this library today - Scalecube. I was looking for implementations of Gossip based membership and these guys implement SWIM in that library.
I took this opportunity to remove atomix also from the core and added it as a separate module.
@brewkode This is also making making baby steps towards rebalancing ( #49 ) following the progress on #43