These are chat archives for atomix/atomix

31st
Mar 2017
Jordan Halterman
@kuujo
Mar 31 2017 00:23
New Copycat/Atomix releases on the way!
We’ve been working on bug fixes and improvements in the general efficiency of the client and related protocols for the last couple weeks. This release primarily includes those improvements to the client, and not much new in Atomix yet.
Jon Hall
@jhall11
Mar 31 2017 00:28
:+1:
Jordan Halterman
@kuujo
Mar 31 2017 01:13
slowly but surely ;-)
probably should try to speed up those tests some time
haha
Copycat 1.2.4 has been released
on to Atomix
Jordan Halterman
@kuujo
Mar 31 2017 05:48
And Atomix 1.0.4
nvySub
@nvySub
Mar 31 2017 11:57
Hi. I'm trying to compile copycat 1.2.4 on windows with java 1.8 and I get the following error java.lang.AssertionError: expected [0] but found [1]
at io.atomix.copycat.server.storage.MetaStoreTest.testDeleteMetaStore(MetaStoreTest.java:115)
has anyone seen a similar problem?
Jonathan Halterman
@jhalterman
Mar 31 2017 14:44

@nvySub Might be a bug in the test threading logic. Can you file an issue along with info on which test is actually failing, stacktraces if you have it, etc?

If you just want to compile, you can skip the tests via -DskipTests=true

Himanshu
@himanshug
Mar 31 2017 15:25
@kuujo in the short term, how do you feel about making configuration protocol optional (i.e. no configuration updates, no join requests, no updating the configuration on disk etc). all the servers are given "list<address> of all servers" and that is strictly what they work with... ... adding/removing node would mean shutting down all servers , updating the config and then restarting them....... that would place us into same world as ZK.
Jordan Halterman
@kuujo
Mar 31 2017 17:50
Hmmm
Jonathan Halterman
@jhalterman
Mar 31 2017 19:11
Sounds like a step backwards, no?
Richard Pijnenburg
@electrical
Mar 31 2017 20:42
@jhalterman how's the new job going?
Jonathan Halterman
@jhalterman
Mar 31 2017 21:46
@electrical Elastic is very very cool. I'm really happy so far :)
Jordan Halterman
@kuujo
Mar 31 2017 22:04
I think it would be incredibly difficult to make the configuration change protocol optional. It heavily integrated into the entire system. Configuration changes occur for more than just nodes being added to/removed from the cluster. I’m not very interested in doing a lot of work to remove a feature TBH
the easiest thing to do would probably be to add a method other than bootstrap/join that initializes/overrides the cluster configuration regardless of whether it already exists
Jordan Halterman
@kuujo
Mar 31 2017 22:11
why would we want to force users to shut down all servers to add/remove a node?
I mean, if a user wants to replace a cluster with another cluster, they just add the second cluster and remove the first
is the problem what happens when a node permanently crashes?
I’m thinking about stealing some of the configuration providers from ONOS. The problem is always just going to be that configurations have to be managed through the log, and it’s difficult to make such a fundamental protocol optional. I mean, Copycat still has APIs that say it’s not optional. What happens to those? We have to have a non-configurable Cluster interface and a configurable one?
we’d have to have a completely separate CopycatServer API that doesn’t have a join method, or uglily throw exceptions if it’s not supported
Jonathan Halterman
@jhalterman
Mar 31 2017 22:15
If it's just about easy recovery, there are probably other approaches.
Jordan Halterman
@kuujo
Mar 31 2017 22:16
I think it makes more sense to make something like that optional if it’s in a standalone service
Copycat is not a service like ZooKeeper. It has a programmatic API that has to be considered.
It may be possible to support overriding the configuration without having some version that doesn’t actually support configuration changes
it’s up to whatever system is using Copycat whether it wants to expose configuration changes