These are chat archives for atomix/atomix

1st
Jun 2016
Roman Pearah
@neverfox
Jun 01 2016 06:19
Is anyone else experiencing an unusually high failure rate for clients connecting to a cluster? I would say that it's somewhere around 1 in 10 attempts that throws an exception, though I don't have any hard numbers or definitive proof that it's not something else going on. It just seems that, absent an actually networking issue, that should rarely happen.
Roman Pearah
@neverfox
Jun 01 2016 06:26
Also, sometime, I just cannot connect at all. The future never resolves and nothing in the logs but replica KeepAlives
Jordan Halterman
@kuujo
Jun 01 2016 07:07
What's the exception? Or different exceptions?
Vincent Devillers
@Treydone
Jun 01 2016 12:28
Hi! I'm looking for the partition feature in Atomix but I couldn't find it after my upgrade (rc3 -> rc7). Did I mess somewhere?
Jordan Halterman
@kuujo
Jun 01 2016 16:53
Nope... It was a difficult decision, but DistributedGrouppartitions were removed as they were determined to be outside the scope of Atomix 1.0, potentially too opintimated, and didn't solve any problem that can't already be solved with DistributedGroup. The same semantics can be achieved simply by maintaining multiple DistributedGroups, and that is the pattern we'd prefer to encourage over more complexity in resources themselves. Resources should be composable and limited in their scope to things that can't be done through composition or client-side operations.
opinionated*
Roman Pearah
@neverfox
Jun 01 2016 17:31
@kuujo Unfortunately, I failed to note it last time, but next time I'll grab the details.
Vincent Devillers
@Treydone
Jun 01 2016 17:53
Ok thanks for the details! So related to this, is there any limit on how many groups a member can be in? If I create a partitionned system with 100 or more partitions, I can do it just by using as many DistributedGroup?
Roman Pearah
@neverfox
Jun 01 2016 17:56
Another thing we've found ourselves needing is a way to look at all the resources on a cluster (mainly so we can prune waste). We have clients creating resources all over the place and I couldn't find any documentation about how to do housecleaning on a cluster, when the client isn't responsible for cleaning it up themselves (since the resource may outlive the client).
Unless, I'm mistaken, the only way to delete something is to know its name ahead of time.
Jordan Halterman
@kuujo
Jun 01 2016 18:07
@neverfox this is actually something I've thought about a bit. I think it could be interesting and is certainly feasible to allow resources to be created with rules for cleanup of their state in the event all clients disconnect. I didn't implement it because I didn't have a specific use case myself, but maybe we can work together on this.
For now, I suppose one would have to read resource names which you can get from the Atomix API
But I'd prefer some sort of cleanup policy
@Treydone there's no practical limit. 100 groups for 100 partitions would be totally fine. The overhead of a resource is its state machine, and a DistributedGroup state machine is just a map of members which should be tiny. Atomix resource shared expensive resources like connections and heartbeats. So, 100 groups will all communicate on the same socket and still have a single heartbeat.
Jordan Halterman
@kuujo
Jun 01 2016 18:13
Ugh can't type on my phone