These are chat archives for atomix/atomix

26th
Jul 2018
toni
@digevil
Jul 26 2018 01:46
@johnou hi Johno, just change from rc3 to rc5, thx, but the log prints identical msg
here is code how i create document tree:
AsyncAtomicDocumentTree<Object> tree = atomix
                .atomicDocumentTreeBuilder(ENV)
                .withProtocol(protocolEnv())
                .build().async();
Jordan Halterman
@kuujo
Jul 26 2018 01:51
What about the operations being performed? The message implies some write failed
toni
@digevil
Jul 26 2018 01:51
here is the protocol:
private MultiRaftProtocol protocolEnv() {
        return MultiRaftProtocol
                .builder(consistencyConfig.getRaftId())
                .withReadConsistency(ReadConsistency.LINEARIZABLE)
                .withMaxRetries(5)
                .build();
    }
operation:
configMap.put("a", nodeConfig.getId().toString()).whenComplete((a, b) -> {
                System.out.println("map hahaha2: " + configMap.get("a").join());
            });
sorry... that is of map
envTree.set(DocumentPath.from("a"), nodeConfig.getId().toString()).whenComplete((a, b) -> {
                System.out.println("tree hahaha1: " + a);
                System.out.println("tree hahaha2: " + b);
            });
Jordan Halterman
@kuujo
Jul 26 2018 01:53
awesome thanks
toni
@digevil
Jul 26 2018 01:54
i also tried lock with:
lockDbRead.lock();
            System.out.println("lock hahaha");
            Thread.sleep(100);
            lockDbRead.unlock();
i saw log for lock and map but didn't see log of tree
Jordan Halterman
@kuujo
Jul 26 2018 02:03

K I reproduced it… this is just bad error handling by the AtomicDocumentTree state machine really. Also bad API design. I’ve always disliked how the paths were written, so I think we can change it.

Basically, the DocumentPath for some reason was written to require a root path. The root path is statically named root. So, to set the path you need to do envTree.set(DocumentPath.from(“root|a”), nodeConfig.getId().toString())

The bug here is really that the state machine is not properly returning an error when the path is malformed. That’s one issue. The other is that we probably don’t need a DocumentPath wrapper at all, and the path shouldn’t use pipes | which are ugly and non-intuitive, and the path shouldn’t require a root for no reason whatsoever.

toni
@digevil
Jul 26 2018 02:04
ice cool
we like the document tree as we have a real document tree to manage by our service cluster, actually its an pmml file list generated by our data team
we need to load them into our service and want to keep the cluster consistency, so we find atomix and we love the document tree structure as it helps us a lot we think
so in short we need to have a root before every path, in long term you might change the document path right, thank's really cool
toni
@digevil
Jul 26 2018 02:15
it works now, thanks:
tree hahaha1: null
tree hahaha2: null
10:14:15.268 [raft-server-raft-partition-1-1] DEBUG i.a.c.m.impl.NettyMessagingService - Established a new connection to localhost:5002
10:14:15.279 [raft-client-raft-partition-1-1] INFO  c.p.i.s.s.c.ConsistencyService - tree event: DocumentTreeEvent{type=CREATED, path=root|a, newValue=Optional[Versioned{value=node2, version=2, creationTime=2018-07-26 10:14:15,261}], oldValue=Optional.empty}
10:14:15.279 [raft-client-raft-partition-1-4] INFO  c.p.i.s.s.c.ConsistencyService - tree event: DocumentTreeEvent{type=CREATED, path=root|a, newValue=Optional[Versioned{value=node2, version=2, creationTime=2018-07-26 10:14:15,261}], oldValue=Optional.empty}
Versioned{value=node2, version=2, creationTime=2018-07-26 10:14:15,261}
Jordan Halterman
@kuujo
Jul 26 2018 02:36

@digevil I’ll put in a PR to change it tonight. Also, any other suggestions about the API are welcome. That one was written by my predecessor.

What I’d like is:
• Remove the root prefix
• Change the default separator from | to . or / (preferences?)
• Simplify some of the methods - allow the set to recursively create or update the tree. In other words, set(DocumentPath.from(“foo.bar.baz”), ...) creates foo and foo.bar and sets foo.bar.baz. The reason we need this is because it currently requires multiple operations to check, create, and set a node like that, and operations are not atomic so the API can cause a lot of race conditions. Maybe this could just be a configuration option, though. The other option would be adding a transactional tree, which is fine, but transactions have a lot of overhead for something that can be implemented in a single method.

multiple* operations are not atomic that is
Jordan Halterman
@kuujo
Jul 26 2018 02:46
Any changes you’d like to see to suit your use case?
Of course, you can also add a new primitive is something doesn’t suit your use case
toni
@digevil
Jul 26 2018 03:01
that would be great!!
Jordan Halterman
@kuujo
Jul 26 2018 18:11
#733
let me know if you need anything else