* Remove ActorContext parameter from javadsl.ReceiveBuilder, #27120
* functional style in javadsl
* in Java it's more practical to have an enclosing class to hold
initialization parameters and ActorContext
* writing behaviors as pure static methods will be unlikely be used in Java
* it's still possible to write behaviors as static methods by passing
the context around, in same way as all other things
* better to embrace the enclosing class pattern and therefore remove
the context parameter from the message handlers
* style cleanup of ChatRoom sample
* migration guide
* Removed `Behavior.same`, `Behavior.unhandled`, `Behavior.stopped`, `Behavior.empty`, and `Behavior.ignore` since
they were redundant with corresponding in Behaviors
* Also moved several of the internal things from Behavior to BehaviorImpl
* previous `schedule` method is trying to maintain a fixed average frequency
over time, but that can result in undesired bursts of scheduled tasks after a long
GC or if the JVM process has been suspended, same with all other periodic
scheduled message sending via various Timer APIs
* most of the time "fixed delay" is more desirable
* we can't just change because it's too big behavioral change and some might
depend on previous behavior
* deprecate the old `schedule` and introduce new `scheduleWithFixedDelay`
and `scheduleAtFixedRate`, when fixing the deprecation warning users should
make a concious decision of which behavior to use (scheduleWithFixedDelay in
most cases)
* Streams
* SchedulerSpec
* test both fixed delay and fixed rate
* TimerSpec
* FSM and PersistentFSM
* mima
* runnable as second parameter list, also in typed.Scheduler
* IllegalStateException vs SchedulerException
* deprecated annotations
* api and reference docs, all places
* migration guide
* migration guide entry
* ManualTime was making assumptions about scheduler
* Add API compile tests for good measure
* named scheduleAtFixedRate instead of schedule
* ClusterReceptionist using own ddata Replicator #26936
* otherwise application configuration, such as role may break it
* creating it as a child actor, path will be same on all nodes
* rolling update from 2.5 not supported
* mention in migration guide
* update migration note about receptionist rolling update
* fix several tests that were using akka.remote.netty.tcp config
* replace akka.tcp with akka in more places
* some doc cross references to remoting.md
* Allow for dispatcher aliases and define a internal dispatcher
* Test checking dispatcher name
* MiMa for Dispatchers
* Migration guide entry
* No need to have custom dispatcher lookup logic in streams anymore
* Default dispatcher size and migration note about that
* Test checking exact config values...
* Typed receptionist on internal dispatcher
* All internal usages of system.dispatcher gone through
This change ignore the terminated passed from untyped and map it into Done,
with some minor changes for testing termination.
termiate() returns Unit to not bias it towards the Scala API, completion
can be observed with whenTerminated or getWhenTerminated
* The scenario was (probably) that a node was restarted with
same host:port and then didn't join the same cluster. The DData
Replicator in the original cluster would continue sending messages
to the new incarnation resulting in false removals.
* The fix is that DData Replicator includes the system uid of the sending
or target system in messages and if recipient gets a message that is from/to
unknown it will discard it and thereby not spreading information across
different clusters.
* Reproduced in ClusterReceptionistSpec
* Much hardening of other things in ClusterReceptionistSpec
* There are also some improvements to ClusterReceptionist to not leak
Listing with refs of removed nodes.
* use ClusterShuttingDown
* The reason for using sender system uid instead of target uid in messages
like Read and Write is that then the optimization for sending same message
to many destinations can remain.
* ⇒, →, ←
* because we don't want to show them in documentation snippets and
then it's complicated to avoid that when snippets are
located in src/test/scala in individual modules
* dont replace object `→` in FSM.scala and PersistentFSM.scala
stuff moved to a new package. you wouldn't expect that in a point
release, but they put type aliases in place so Scala users wouldn't
notice. but the change is visible to Java code.
the upgrade is not strictly necessary, but it would be convenient
for the Scala 2.13 community build to have this merged, so I don't
have to maintain these changes in our Akka fork
* Make the AbstractBehavior builder mutable #26260
* Use mutable builder style in first sample, mention that fluent is an option
* A bit of rework of the Java builders:
* onAnyMessage added
* use the japi SAMs throughout in the APIs
* avoid wrapping the japi functions in Scala functions for the most common cases
* more Java test coverage
* Not just any exception
* Works on 2.11 as well as 2.12
* Walk stack to figure out logger class
* User API for getting a customized logger
* API to set logger class, use in receptionists, auto-good-class for EventSourcedBehavior
* problem found by new EventSourcedBehaviorStashSpec
* added tests of this in SupervisionSpec
* the scheduled ScheduledRestart and ResetRestartCount need an
owner field so that they can be passed on if not scheduled by
the strategy instance itself
* Increase patience for ReceptionistExampleSpec
This test doesn't extend AkkaSpec doesn't pick up the larger patience
for other tests
* Remove unused examples from example specs
* Formatting
* use receiveOne instead of receiveMessageType, #25914
* when the type is the same as the probe's type
* formatting
* rename receiveOne to receiveMessage
* rename receiveN to receiveMessages
* have to use different name in javadsl so that became receiveSeveralMessages
* Add CopyrightHeader support for sbt-boilerplate plugin.
* Add CopyrightHeader support for `*.proto` files.
* Add regex match for both `–` and `-` for CopyrightHeader.
* Add CopyrightHeader support for sbt build files.
* Update copyright from 2018 to 2019.
* Introduce 'MemberDowned' member event
Compatiblity note: MemberEvent is a sealed trait, so it is debatable whether
it is acceptable to introduce a new member.
* Be more conservative (more like leaving), add test
