These are chat archives for atomix/atomix

8th
Jun 2018
Johno Crawford
@johnou
Jun 08 2018 08:09
@kuujo sure you want to mix all the renaming with using the thread context to track blocked threads?
Jordan Halterman
@kuujo
Jun 08 2018 08:11
nope
Jordan Halterman
@kuujo
Jun 08 2018 08:16
I will make them separate PRs
almost done
Johno Crawford
@johnou
Jun 08 2018 08:17
is it safe to remove the other executors?
Ronnie
@rroller
Jun 08 2018 15:10
with the latest snapshot i'm getting java.lang.NoClassDefFoundError: io/atomix/protocols/backup/partition/PrimaryBackupPartitionGroupConfig
my dependencies are
      <dependency>
        <groupId>io.atomix</groupId>
        <artifactId>atomix</artifactId>
        <version>2.1.0-SNAPSHOT</version>
      </dependency>
      <dependency>
        <groupId>io.atomix</groupId>
        <artifactId>atomix-raft</artifactId>
        <version>2.1.0-SNAPSHOT</version>
      </dependency>
do we now need to directly depend on atomix-primary-backup?
Ronnie
@rroller
Jun 08 2018 15:15
Depending on that does appear to fix it
Jordan Halterman
@kuujo
Jun 08 2018 16:49
@johnou what executors are you referring to?
Hmm that’s strange. Nothing in the core has any reference to the protocol implementations any more. Maybe just need to deploy the snapshot again. The only way this should be possible is if another node configured a primary-backup partition group, in which case all nodes need to have the jar to be able to connect to the partitions.
Ronnie
@rroller
Jun 08 2018 17:00
weird. I didn't change any of my code, just refreshed the snapshot
Jordan Halterman
@kuujo
Jun 08 2018 17:52
The snapshot probably didn’t get deployed. Previously this was an issue
I will do it manually again
On another note, I pretty much have all the API changes done now. Just ran into another CompletableFuture ordering issue wherein futures are sometimes being completed in reverse order again. Have to fix that before merging all the changes, then should be able to do the version bump.
Johno Crawford
@johnou
Jun 08 2018 20:45
maybe it wasn't used anymore
yeah i saw you removed a bunch of ordered futures
Jordan Halterman
@kuujo
Jun 08 2018 21:47
actually those were a different kind of ordered future… duplicate names for slightly different behaviors
Johno Crawford
@johnou
Jun 08 2018 21:47
ah
Jordan Halterman
@kuujo
Jun 08 2018 21:47
that Futures.orderedFuture method is replaced by the BlockingAwareThreadContext
making slow progress here but it’s hard as hell to debug ordering issues in threads
Johno Crawford
@johnou
Jun 08 2018 21:48
yeah breakpoints don't help
Jordan Halterman
@kuujo
Jun 08 2018 21:54
it’s like 20% of the times I try a few concurrent operations they get completed in reverse order
Johno Crawford
@johnou
Jun 08 2018 22:06
i don't think atomix uses a fjp right?
Jordan Halterman
@kuujo
Jun 08 2018 22:09
this is one of those times I look in the reflection of my screen saver and wonder how I got here
Johno Crawford
@johnou
Jun 08 2018 22:12
few operations with what primitive
Jordan Halterman
@kuujo
Jun 08 2018 22:12
no primitive
Johno Crawford
@johnou
Jun 08 2018 22:22
what commit does it start from?
atomix/atomix@15d2a54
?
Jordan Halterman
@kuujo
Jun 08 2018 22:33
nope
It has nothing to do with blocked thread checking, the problem is chaining client.connect().thenCompose(v -> client.execute(…)) when client.connect() returns a future that multiple callers then call thenCompose on, and those callbacks are called out of order. The problem seems to just be that the ordered futures are being obscured by more futures
anyways, pretty sure I just figured it out based on that
indeed I did
just gotta clean up this code now
Jordan Halterman
@kuujo
Jun 08 2018 22:38
I made a mess of this thing trying to figure that out
Johno Crawford
@johnou
Jun 08 2018 22:38
nw
Jordan Halterman
@kuujo
Jun 08 2018 22:44
The lack of any semblance of order in CompletableFuture callbacks has been a major PITA. We don’t want to allocate queues for every single future. Atomix creates futures like crazy. Although I guess allocating a linked list isn’t really a big deal so maybe should just generalize it to all the futures.
But any future that has the potential for multiple stages to be added to it needs to be using OrderedFuture at least
Ronnie
@rroller
Jun 08 2018 22:48
that sound scary, glad you got it figured out :)
Jordan Halterman
@kuujo
Jun 08 2018 22:53
We should probably take a stab at removing Guava some time. The biggest hurdle is just the murmur hash implementations, but we can at least replace it with one of the many standalone murmur implementations in existence.
Ditto commons libraries, which should be pretty simple.