1. 10
  1.  

  2. 8

    I submitted this so I’d like to point out that in a distributed system, exactly once is a lie. You can do “usually” once but never exactly once. There are simply too many failure scenarios.

    Rather than building systems for semantics like exactly once, I think we would be better of building systems that embrace uncertainty and failure.

    At least once systems backed by idempotent operations, CRDTs and a variety of other systems are far more interesting to me and, more likely to move us forward.

    1. 2

      Rather than building systems for semantics like exactly once, I think we would be better of building systems that embrace uncertainty and failure.

      Tend to agree. I tell people to just make their reducers/processors/workers idempotent rather than try to make the impossible happen on the dist-sys side.

      At least once systems backed by idempotent operations, CRDTs and a variety of other systems are far more interesting to me and, more likely to move us forward.

      Kontiki could use some love. :)

      Kafka client is coming together for Haskell by the way, if at-least-once messaging is important to you.

      Edit: more info on the topic:

      http://stackoverflow.com/questions/416551/why-is-exactly-once-semantics-infeasible

      http://www.infoq.com/articles/no-reliable-messaging

      http://ilpubs.stanford.edu:8090/483/1/2000-7.pdf

      http://kafka.apache.org/documentation.html#semantics http://rabbitmq.1065348.n5.nabble.com/Exactly-Once-Delivery-td16826.html

      1. 2

        Hey Sean, thanks for the invite!

        It looks to me like they are doing something quite similar to CRDTs by permitting inner operations only to take the form of commutative monoids (http://hailstorm-hs.github.io/hailstorm/demo/#15), which in combination with their low water mark idea would appear to give one a solid ‘exactly once’ semantic (under the proviso that your operations must be relatively strictured in type).

        It would be interesting to see a proof of their assertions, but on the other hand, this sort of thing seems to be the right direction: an attempt to tie AP to “the real world” by trying to provide a linearizability-style consistency guarantee at the edge. Compare and contrast with, e.g., {last-write-wins, false}.

      2. 1

        What is exactly once semantics? If anyone can explain it to me simply?

        1. 1

          I linked some more in depth materials in the topic in the other branch of the thread, but it basically means guaranteeing that you’ll send each message once and only once.

          Guaranteeing message delivery is just that. That doesn’t necessarily mean it won’t get sent twice, three times, etc.

          Exactly-once messaging requires consistency if I understand correctly.

          1. 2

            Exactly-once is harder even than just having a sequentially consistent system. It is, in fact, impossible–suppose you want to send a fax (bear with me :)) exactly once when a certain event happens. Then, suppose that the call to sendFax() throws an exception. How can you know whether the fax went out or not, if the error says “didn’t recieve ACK”? This fact, that there’s always some action that isn’t part of your nice, sequentially consistent data model, is what forces every real system to make compromises.

            1. 1

              okay, thanks. Didn’t know it was such a difficult problem.

              1. 1

                Most computer stuff is like that :)