These are chat archives for RBMHTechnology/eventuate

20th
Dec 2016
Martin Krasser
@krasserm
Dec 20 2016 07:53 UTC
sounds reasonable
Alexander Semenov
@Tvaroh
Dec 20 2016 10:35 UTC
@krasserm why that test above is called CRDTChaosSpecLeveldb when in fact it's ORSetChaosSpecLeveldb?
Martin Krasser
@krasserm
Dec 20 2016 10:47 UTC
@Tvaroh seems that a bad name has been chosen
Alexander Semenov
@Tvaroh
Dec 20 2016 10:48 UTC
I see, naming is hard :)
Alexander Semenov
@Tvaroh
Dec 20 2016 11:03 UTC

@krasserm I'm trying to grab MultiLocationSpecLeveldb from eventuate-log-leveldb module but looks like you don't publish test artifacts, are you?

https://dl.bintray.com/rbmhtechnology/maven/com/rbmhtechnology/eventuate-log-leveldb_2.12/0.8.1/

Martin Krasser
@krasserm
Dec 20 2016 11:19 UTC
Test artifacts are only published for eventuate-core at the moment. Please open a ticket if you want to have those of eventuate-log-leveldb and/or eventuate-log-cassandra as well
or better, create a PR :smiley:
Alexander Semenov
@Tvaroh
Dec 20 2016 11:23 UTC
will do the PR, thanks!
Martin Krasser
@krasserm
Dec 20 2016 11:30 UTC
thank you!
Alexander Semenov
@Tvaroh
Dec 20 2016 11:56 UTC

@krasserm RBMHTechnology/eventuate#374

Should I also do one targetting r-0.8 branch?

Martin Krasser
@krasserm
Dec 20 2016 11:58 UTC
No, master only is fine. Thanks!
Alexander Semenov
@Tvaroh
Dec 20 2016 12:01 UTC
you're welcome. Is master branch stable? I'm going to switch to it for now (having previously missing artifacts published locally).
Alexander Semenov
@Tvaroh
Dec 20 2016 16:36 UTC

@krasserm I'm getting akka.pattern.AskTimeoutException when throwing an exception at source phase (in prepare method). When I throw at downstream (effect method) then it even loops for some time rethrowing exception many times and then still fails with ask timeout.

So I wonder how am I supposed to return errors from prepare phase? E.g. if parent is missing or node already exists?

Gabriel Giussi
@gabrielgiussi
Dec 20 2016 16:56 UTC
With the current implementation of CRDT i think tou should return None in that case, and validations against the current state of the CRDT must be done at service level.
Alexander Semenov
@Tvaroh
Dec 20 2016 17:01 UTC
@gabrielgiussi ah, that does make sense but not sure how applicable it is for my case. In the CRDT itself I maintain some maps that allow to quickly check if a node (by id or by parent id - I'm talking about a tree) does exist. Otoh at the service layer I don't have access to that info and I can only try using value method though that's unacceptable (too much redundant expensive operations).
Alexander Semenov
@Tvaroh
Dec 20 2016 17:16 UTC
I feel like prepare method should return Option[Try[...]] instead of Option
Martin Krasser
@krasserm
Dec 20 2016 17:21 UTC

throwing an exception at source phase

CRDTService must be extended to support command rejections. That use case didn't exist so far. Should be easy to add. Please create a ticket or PR.

throw at downstream

then you're doing something wrong. I didn't look at your code in detail yet but running an operation downstream is like applying an event. Events cannot be rejected in contrast to commands but must be handled (automatically resolving a conflict if needed).

Alexander Semenov
@Tvaroh
Dec 20 2016 17:22 UTC
Martin, I don't throw at downstream, it was just a crazy stupid idea to check, then I reverted.
currently working on supporting throwing at source
Martin Krasser
@krasserm
Dec 20 2016 17:23 UTC
Ok then
I'd rather propose that prepare should return Try[Option[...]]
Alexander Semenov
@Tvaroh
Dec 20 2016 17:23 UTC
so when no action required one should return Success(None) - works for me
Martin Krasser
@krasserm
Dec 20 2016 17:24 UTC
yes
Alexander Semenov
@Tvaroh
Dec 20 2016 17:24 UTC
:+1:
Gabriel Giussi
@gabrielgiussi
Dec 20 2016 17:30 UTC
Being operation rejection a common use case, I wonder why wasn't considered in the original paper. @krasserm do you think is worth to ask Carlos Baquero?
I mean, in a pure op based CRDT prepare is just prepare ( o; ( s;p )) = o, so aren't we deviating from the original specification?
Martin Krasser
@krasserm
Dec 20 2016 17:42 UTC
@gabrielgiussi right, in a pure op-based approach, there is never command validation, only conflict resolution. That's maybe the cleaner approach. OTOH the paper used by @Tvaroh specifies CRDTs in terms of pre- and post-conditions, hence we need that addition I think.
Martin Krasser
@krasserm
Dec 20 2016 17:44 UTC
yes, thanks for posting the link again
Alexander Semenov
@Tvaroh
Dec 20 2016 17:46 UTC
Well, it's possible to move the validation to the command handler out of the CRDT. But then the CRDT would be kind of useless by itself without using some accompanying command handlers.
probably, self-contained CRDT is better for a user
Gabriel Giussi
@gabrielgiussi
Dec 20 2016 17:54 UTC
I agree that command validation must be done inside CRDT because he owns the state and could do some optimizations when querying it that service couldn't because he receives the complete value. I just was "worried" about adding semantic to prepare, but I'm ok with that. @Tvaroh you'll do the PR with the modified prepare and CRDTActor command handler?
Alexander Semenov
@Tvaroh
Dec 20 2016 17:55 UTC
yes, currently testing my changes
in a minute
Alexander Semenov
@Tvaroh
Dec 20 2016 18:03 UTC
btw I've sent an email for the CLA thing, didn't get a response back yet
Martin Krasser
@krasserm
Dec 20 2016 18:10 UTC
@Tvaroh hmm, if you still haven't got an answer tomorrow morning, please ping me again. Thanks
Alexander Semenov
@Tvaroh
Dec 20 2016 18:18 UTC
Sure np