* off by one when accessed from event handler
* off by one from event handler during replay
* wrong when unstashing
* added more tests, also for persist of several events
* using real EventSourcedBehaviorImpl
* using new inmem journal (PersistenceTestKit)
* advantages compared to a "fake" driver
* no difference in implementation details from real thing
* no limitations
* less maintance
* added internal messsages to EventSourcedBehaviorImpl to be able to grab state
and persistenceId
* GetState as InternalProtocol instead of Signal so that it is stashed
* serialization checks, using SerializationTestKit
* better testKitGuardian naming to allow multiple PersistenceTestKit
* support testing of restart
* support failure testing by using PersistenceTestKit
* update doc sample
* apidoc, reference docs, and javadsl
* Add scalafix plugin for jdk 9.
* Add command alias sortImports.
* Excludes some sources from SortImports.
* Update SortImports to 0.4.0
* Sort imports with `sortImports` command.
* scalafix ExplicitNonNullaryApply prepare
+ Temporarily use com.sandinh:sbt-scalafix because scalacenter/scalafix#1098
+ Add ExplicitNonNullaryApply rule to .scalafix.conf
+ Manually fix a NonNullaryApply case in DeathWatchSpec that cause
`fixall` fail because ExplicitNonNullaryApply rule incorrectly rewrite
`context unbecome` to `context unbecome()` instead of `context.unbecome()`
* scalafix ExplicitNonNullaryApply
fix by enabling only ExplicitNonNullaryApply rule in .scalafix.conf then:
```
% sbt -Dakka.build.scalaVersion=2.13.1
> fixall
```
* scalafmtAll
* Revert to ch.epfl.scala:sbt-scalafix
Co-authored-by: Bùi Việt Thành <thanhbv@sandinh.net>
Different approach than in classic AtLeastOnceDelivery because I would like:
* support flow control, with a work pulling approach
* be possible to use with or without persistence (without it may loose
messages if producer node crashes)
* detect lost messages on the consumer side and let that drive resends,
instead of aggressively resending from producer side
* deliver messages in order and deduplicate resent messages
* have an efficient protocol for acknowledgments over the network (not ack each message),
but still have a simple one-by-one protocol for the end user
* support 3 use cases (building blocks)
* point-to-point
* work pulling
* sharding
* optional durable queue, with one event sourced implementation
* protobuf serialization
* ApiMayChange
* reference docs and examples
* api docs
* doc example code missing so far
* Add paramater documentation for event sourced entities
Useful for help in IDEs, text taken from the docs.
* whitespace
Co-authored-by: Arnout Engelen <github@bzzt.net>
It's not actually shown in docs anywhere, only exists for Scala, and has questionable semantics.
If #24473 is ever revived I guess we should/can reintroduce the sample, include in docs, make it work etc.
* Add convenience method to start timer without key
It is probably common that there is no need to allow different timers
that send the same message, and this makes that more convenient to write.
Updated one method to gather feedback, if we like the change I can apply
it to the others as well.
* Add alternative to all typed timer API's
Update java/scaladoc, update tests
Not updated classic actors and FSM API's
* backport from Classic
* the scenario was that the snapshot was kept but the journal was
entirely deleted, and then it should anyway write next event
with the sequence number from the snapshot
* doesn't look like the EventSourcedBehavior had this problem,
but doesn't hurt to use the max
* Not working for mysterious reasons
* Fix for #27507 race in test
Logging at debug to try if there is a race when testing on Jenkins
Also, fail fast if expecting a signal from a TestProbe (never happens)
Some minor logging improvements for event sourced behavior as well.
* Don't send batches of events when snapshot and event deletion is enabled
When events are deleted the event sourced actor switches to running until it gets
an ack back from the journal about deleting events, then it deletes snapshots if that
is enabled. This means events and snapshotting could happen inbetween making the
ordering of SnapshotComplete and DeleteSnapshotsComplete signals non deterministic.
