The sentence is incomplete as is, this adds the words "is logged" to the
middle of:
..., then the complete configuration at INFO level when the
actor system is started."
Previously know as [patriknw/akka-data-replication](https://github.com/patriknw/akka-data-replication),
which was originally inspired by [jboner/akka-crdt](https://github.com/jboner/akka-crdt).
The functionality is very similar to akka-data-replication 0.11.
Here is a list of the most important changes:
* The package name changed to `akka.cluster.ddata`
* The extension was renamed to `DistributedData`
* The keys changed from strings to classes with unique identifiers and type information of the data values,
e.g. `ORSetKey[Int]("set2")`
* The optional read consistency parameter was removed from the `Update` message. If you need to read from
other replicas before performing the update you have to first send a `Get` message and then continue with
the ``Update`` when the ``GetSuccess`` is received.
* `BigInt` is used in `GCounter` and `PNCounter` instead of `Long`
* Improvements of java api
* Better documentation
This can be used to traverse NATs with the following configuration:
akka.remote.netty.tcp {
...
hostname = my-external-address.lt
bind-hostname = 192.168.1.100
}
Use Akka BoundAddressesExtension to get bound addresses
* The filter is used by the LoggingAdapter before publishing
to the event bus
* Slf4jLoggingFilter uses backend log level configuration
(e.g. logback.xml)
* also remove final of around methods, and let deliver send when not recoveryRunning
(cherry picked from commit 312b0d107a179accaf135f64ed9c3b78f3e351d1)
* Based on Jonas' notes: https://gist.github.com/jboner/7692270
* Also removed "Future Extension" descriptions of cluster actor reference,
since that is probably not the direction we are taking
* because it is not referentially transparent; normally we reserved parens for
side-effecting code but given how people thoughtlessly close over it we revised
that that decision for sender
* caller can still omit parens
- Built-in redelivery mechanism for Channel and PersistentChannel
- redelivery counter on ConfirmablePersistent
- redeliveries out of initial message delivery order
- relative order of redelivered messages is preserved
- configurable redelivery policy (ChannelSettings)
- Major refactorings of channels (and channel tests)
- Throughput load test for PersistentChannel
Todo:
- Paged/throtlled replay (another pull request)
- Resequencer (another pull request)
