At the moment, there is one EventsourcedActor per CRDT type. While this is sufficient for CRDTs that don't require precondition checks atSource it limits write throughput for those that require these checks.
In the latter case, the EventsourcedActor must have set stateSync to true which more or less turns off write batching for a single actor.

By distributing CRDT instances of a given type across actors, their concurrent writes can be batched again by BatchingEventLog, increasing write throughput. The cost is more memory overhead per CRDT instance. Ideally, the user can configure whether to use the one-actor-per-CRDT-instance or the (current) one-actor-per-CRDT-type approach.

Another advantage of having one EventsourcedActor per CRDT instance is that they can be loaded and discarded from memory on demand. With a reasonably small number of updates per CRDT instance (e.g. < 500) snapshots may not be necessary either.

This can be achieved by allowing an EventsourceActor (= aggregate) to consume from multiple logs and only write to one of these logs. Aggregate replicas with the same aggregate id write to different logs but consume from all of them, so that distributed writes to the same aggregate id don't need to be merged into a single log. For example, with three (optionally replicated) logs, A, B and C and three aggregate replicas r1, r2 and r3:

• r1 writes to A and reads from A, B and C
• r2 writes to B and reads from A, B and C
• r3 writes to C and reads from A, B and C

This means that replicas ri need to be recovered from three logs (instead of one) and deterministic (= totally ordered) replay is not possible any more. However, by re-ordering concurrently replayed events based on their vector timestamps, causal ordering can be achieved.

A rewrite of the old user guide

See this discussion thread.

Build 112

Eventsourced#log name collides with ActorLogging#log.

This is only relevant if they are operated on the same event log.

#45 introduces basic routing capabilities. This should be extended to allow

• producers to publish events to application-defined topics and
• consumers to consume events from application-defined topics

Topic-based event routing must preserve causality of events and should be possible for event routing between actors that share a single, distributed log. Routing across different logs can be done with processors.

Furthermore, it should be investigated if routing decisions must be made persistent, so that past routings are repeatable. On the other hand, a changed routing rule is somewhat equivalent to changed event handler logic which isn't persistent either.
#130 could be used as implementation basis.

Update notifications from event log to replication servers are too fine-granular at the moment. Send update notifications in larger batches, especially when load is high. Under low and moderate loads, update notifications should dynamically become more fine granular. This shall significantly reduce the number of update notifications sent from a replication server to replication clients over the wire.

Efficiently support the pattern to have one DDD Aggregate per EventsourcedActor. The example application still follows the many aggregates per actor pattern but it has already been re-written by @remcobeckers to follow the one aggregate per actor pattern (see also this discussion). Eventuate should support efficient implementations of this pattern by providing the following enhancements:

• the event log must be indexed by aggregate id for efficient recovery of individual aggregates
• if an aggregate actor writes an event, the event log should only notify those aggregate actor replicas with the same aggregate id (and not all other actors subscribed to the event log). Nevertheless, EventsourcedViews or non-aggregate EventsourcedActors continue to receive all events written to the event log (to support the one view for many actors pattern, for example).
• implement EventsourcedAggregate as specialization of EventsourcedActor to support implementing the one aggregate per actor pattern. Update: EventsourcedActor has an optional aggregateId.
• consider implementing aggregate services similar to CRDT services to free applications from dealing with low-level details.
• the one aggregate per actor prototype is already implemented in a way that vector clock sizes scale with the number of replicas only instead of the potentially large number of aggregates. Ensure that an implementation of EventsourcedAggregate cannot break this property.

• reStructuredText
• Sphinx
• Automated deployment of generated docs and scaladocs from Travis CI

At the moment the copyright and licence header on top of every source file is very sparse.
We should add the URL to the Red Bull Media House in the copyright and also add the licence text that is proposed in the Apache2 license.

Full header that should be applied:

Copyright (C) 2015 Red Bull Media House GmbH <http://www.redbullmediahouse.com> - all rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); 
you may not use this file except in compliance with the License. 
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed 
under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES 
OR CONDITIONS OF ANY KIND, either express or implied. 
See the License for the specific language governing permissions and limitations under the License.

As EventSourcedActors are most likely deployed in two different locations and the log gets replicated over the internet it would be very beneficial to have encryption between two endpoints.

This fixes an O(n*n) stash/unstash overhead issue where n = number of messages in the actor mailbox.

Trigger another batch replication immediately if previous replication had maximum batch size.

Setting of actor ref provider and enabled transports can be overridden because the load order of all reference.conf on the classpath is not defined. Eventuate applications must set these explicitly in application.conf.

This is needed to avoid interference of internal stash operations with user stash operations.

A replication endpoint should support the replication of multiple logs. Here, each log represents a partition and causality is preserved only within a partition.

In the following example, two partitions, named "log1" and "log2", are created for the local replication endpoint and connections are established to remote replication endpoints listening at 127.0.0.1:2553 and 127.0.0.1:2554. The system expects that remote endpoints also have partitions with the same names.

val logNames = Set("log1", "log2")
val connections: Seq[ReplicationConnection] = Seq(
  ReplicationConnection("127.0.0.1", 2553),
  ReplicationConnection("127.0.0.1", 2554))

new ReplicationEndpoint("my-endpoint-id", logNames, id => 
  LeveldbEventLog.props(id), connections)(system)

Log partitioning is not only useful for partitioning events (for example, to support multiple tenants) but can also be used to scale writes (assuming this is also supported by the underlying storage). However, having multiple logs per replication endpoint is not a prerequisite for horizontal scaling; this can also be achieved by deploying logs (i.e. partitions) on different machines, each having its own replication endpoint, for example.

• Detect and ignore duplicates
• Atomic write of replication progress and events

For batching writes of

• a single or multiple event sourced actors running with sync = true
• multiple event sourced actors running with sync = false

The batching layer must be optimized for latency with growing batch sizes (up to a maximum) under increasing load.

The batching layer has no effect when running a single event sourced actor running with sync = true because the actor submits the next write when previous write finished.

• Clean separation of public from private API
• Drop backwards compatibility to initial prototype API

Support operation-based CRDTs as described in A comprehensive study of Convergent and Commutative Replicated Data Types.

An initial implementation should support:

• Counter (specification 5)
• ORSet (specification 15)
• MV-Register (op-based specification not part of paper)

As replication can happen over the internet authentication for replication connections should be supported.

After #36 is implemented, events are routed to Eventsourced actors (= destinations) based on the following default rules:

1. if destination.aggregateId is not defined, the destination will receive all events regardless whether event.aggregateId is defined or not.
2. if destination.aggregateId is defined, the destination will only receive events with matching event.aggregateId.

This shall be generalized to allow custom routing to destinations. When persisting events, EventsourcedActors should be able to specify a set of additional aggregate ids as routing destination. The default routing behavior as described above should be preserved.

An EventsourcedActor should also be able to opt-out from routing of events to replicas with the same aggregate id (by specifying an empty set). In this case, the only consumer of the event is the emitting EventsourcedActor. Routing of events to destination that have no aggregate id defined cannot be overriden. These destination must always receive all events from the event log (but can of course choose to ignore them).

Vector clock size should scale with the number of actual event collaborators and not with the total number of EventsourcedActors on the same distributed log. In other words, only those events that are actually handled by an EventsourcedActorcontribute to its vector clock.

At the moment, replication is based on Akka Remoting which doesn't support NAT (see also this discussion).

Counter and MVRegister can be operated in an EventsourcedActor that is configured with sync = false as these CmRDTs don't need to check pre-conditions in update phase 1. This optimization has a significant impact on throughput.

• Build
• Sphinx installation
• Contributing
• ...