* When using the Processor batching buffer for persistAsync and defer
the events were unstashed by Processor.aroundPreRestart and
thereby were received as commands after restart
* Instead we must flush this buffer when using PersistentActor
(cherry picked from commit 627ce2fc85739e221524ec48725362ef7c0566ea)
* I suspect that the issue #15440 happens because of replay of events
in wrong order (ShardHomeAllocated received before ShardRegionRegistered)
by the hbase journal
* This does not fix that issue, but the additional invariant checks and
debug statements would perhaps make it easier for us to diagnose such
issues
* These changes also ensures that the allocation strategy does not return
the wrong thing.
* It also tightens a possible error if a region is terminated while a
rebalance is in progress
(cherry picked from commit d07b9db4958236d580b8bfb8f92461969ff88cbc)
We must first release akka-stream with dependency to akka 2.3.4
and it should be maintained in the akka-release-dev branch
(cherry picked from commit a97a067701cfc527b235707882e72326277415f3)
Conflicts:
akka-samples/akka-sample-persistence-scala/build.sbt
akka-samples/akka-sample-persistence-scala/src/main/scala/sample/persistence/StreamExample.scala
We have assumed that the handlers can be popped when replies come back from journal, but if messages to journal are in flight when the actor is restarted the handlers does not match up with journal replies.
This solution ignores journal replies that were emitted by an old PersistentActor instance
by passing an uid with the journal messages. This means that the handler will not be
invoked for such messages.
(cherry picked from commit 7ebaaab669c9e467a1ffb4d9ed8b6500e1801a7c)
Conflicts:
akka-persistence/src/main/scala/akka/persistence/JournalProtocol.scala
akka-persistence/src/main/scala/akka/persistence/Processor.scala
akka-persistence/src/main/scala/akka/persistence/journal/AsyncWriteJournal.scala
* A few more adjustments, found when verifying source compatibility of a few
journal plugins
* Note that PersistentId will be removed with deleteMessage and we should
not break plugins because of that
* Add missing section of at-least-once delivery in migration guide
(cherry picked from commit 6727eac6d07280d277968e2e25db44e02be3b102)
Conflicts:
akka-persistence/src/main/scala/akka/persistence/JournalProtocol.scala
akka-persistence/src/main/scala/akka/persistence/Persistent.scala
akka-persistence/src/main/scala/akka/persistence/Snapshot.scala
akka-persistence/src/main/scala/akka/persistence/journal/AsyncWriteProxy.scala
* It was detected previously as well when trying to find constructor,
but with a perhaps confusing error message
(cherry picked from commit 15e964b13e91962474c7907787c37121aae8fd4e)
* also remove final of around methods, and let deliver send when not recoveryRunning
(cherry picked from commit 312b0d107a179accaf135f64ed9c3b78f3e351d1)
A PersistentView works the same way as View did previously, except:
* it requires an `peristenceId` (no default is provided)
* messages given to `receive` are NOT wrapped in Persistent()
akka-streams not touched, will update them afterwards on different branch
Also solves #15436 by making persistentId in PersistentView abstract.
(cherry picked from commit dcafaf788236fe6d018388dd55d5bf9650ded696)
Conflicts:
akka-docs/rst/java/lambda-persistence.rst
akka-docs/rst/java/persistence.rst
akka-docs/rst/scala/persistence.rst
akka-persistence/src/main/scala/akka/persistence/Persistent.scala
akka-persistence/src/main/scala/akka/persistence/View.scala
* This is NOT binary compatible, we're in an *experimental* module.
* disabled binary compat checks for package akka.persistence
* Source compatibility is retained, but users should migrate do the new
method name ASAP.
* Plugin APIs were migrated in a way that allows the old plugins to
compile agains 2.3.4 without having to change anything. Hopefuly this
will help authors migrate to 2.3.4 sooner. This is only source level compatible, not binary compatible.
* added deprecation warnings on all processorId methods and provided bridges where possible
* for users, the migration should be painless, they can still override
the old method, and it'll work. But we encourage them to move to
persistenceId; All delegation code will have to be removed afterwards ofc.
Conflicts:
akka-persistence/src/main/scala/akka/persistence/Channel.scala
akka-persistence/src/main/scala/akka/persistence/JournalProtocol.scala
akka-persistence/src/main/scala/akka/persistence/Persistent.scala
akka-persistence/src/main/scala/akka/persistence/PersistentChannel.scala
akka-persistence/src/main/scala/akka/persistence/Processor.scala
akka-persistence/src/main/scala/akka/persistence/Snapshot.scala
akka-persistence/src/main/scala/akka/persistence/journal/AsyncWriteProxy.scala
akka-persistence/src/main/scala/akka/persistence/journal/inmem/InmemJournal.scala
akka-persistence/src/main/scala/akka/persistence/journal/leveldb/LeveldbKey.scala
akka-persistence/src/main/scala/akka/persistence/snapshot/SnapshotStore.scala
akka-persistence/src/test/scala/akka/persistence/serialization/SerializerSpec.scala
project/AkkaBuild.scala