+str #24229 remove protobuf changes, which do not need to be made in this PR
docs
moved things
config object
subscription timeout confifmed working, also, attributes
document attributes for sub timeout
tests for the source also failing when it should
additional demand test
implemented protection from materializing "in cycles"; would be nice in
types but that breaks the niceness of use of the types
SinkRef/SourceRef...
cleanup
no idle timeout built in, can use the Timeout stages
more docs
simplest change to prevent exposing SinkRef => SourceRef => SinkRef cycle
Things to decide:
* is it ok to require using `getSource` / `getSink` as Java API, is there better naming?
* where should the constructors go? I'd say just in regular javadsl/scaladsl `Source`/ `Sink` objects
move constructors to {javadsl,scaladsl}.{Source,Sink} companion objects
Remove now useless "canMaterialize" field
Separate stage (implementation) from ref (wrapped actor ref) to make it clearer what is serialized
Clarify that partner refs are not optional in on-the-wire interfaces
minor cleanup in SourceRefStage
Renamed the stages but questionable if that really helps ;)
cleanups, better docs
cleanup, fix docs compilation
fix mima
got rid of Futures in the materialized values of stream refs
silly serialization mistake, should have fixed serialize as well
tage actors now can have names, which helps a lot in debugging
thread weirdness
make sure to fail properly, actually go over remoting
issue with not receiving the SinkRef... what
initial working SinkRef over remoting
remote Sink failure must fail origin Source as well
cleaning up and adding failyre handling
SinkRef now with low-watermark RequestStrategy
source ref works, yet completely duplicated code
* Utility for stashing, #22275
* The main reason for providing these utilities and promote
a standardized way of doing the buffering is that monitoring
instrumentation can be added to these classes, which is not
possible if we just say "buffer in some collection".
* unstash a few at a time, became rather complicated
* separate api and impl, and more tests
Untyped actor systems currently only support specifying dispatchers via a
name reference to the config. The other selectors can be revived when other
ways of configuring dispatchers are available for untyped actor systems
(see #17568).
* The technical reason for not naming it Behavior is that
it would be duplicate import conflicts of
akka.actor.typed.Behavior and akka.actor.typed.scaladsl.Behavior
* Plural naming is pretty common for factories like this,
e.g. java.util.Collections
* Allow tagging in persistence typed (#23817)
* Use Set[String] for tags
* Documentation for persistence typed tagging
* Rename tagging parameter to tagger
* More generous timeout in DaemonicSpec
Also:
* allow it to complete faster if possible
* avoid potential race with port number
* always shut the extra actor system down
* less dilation
This test is using the tcp ports assigned from the multi-jvm infra (classic remoting)
for the Aeron udp. Even though tcp and udp ports are independent and same port number
can be used at the same time for tcp and udp there is no guarantee that the udp port
is free just because the tcp port was.
* When leaving/downing the last node in a DC it would not
be removed in another DC, since that was only done by the
leader in the owning DC (and that is gone).
* It should be ok to eagerly remove such nodes also by
leaders in other DCs.
* Note that gossip is already sent out so for the last node
that will be spread to other DC, unless there is a network
partition. For that we can't do anything. It will be replaced
if joining again.
* There might be one case when the singleton coordinator
hand over might start before the gracful stop of the
region is completed on other node.
* I think this is rare enough to just accept that message
might be sent to wrong location (we don't guarantee anything
more than best effort anyway).
* Safe rolling upgrade should keep the coordinator (oldest)
until last to avoid such races
* Use expectNoMessage in typed testkit
Interestingly most calls to expectNoMsg did not appear to expect the parameter
to be dilated
Might be nice to allow configuring a variant that uses a (configurable) default
delay (other than the single-expect-default)
* Add a probe.expectNoMessage with no parameters
If you want to 'just wait a while' and not care too much about how long
exactly, will be dilated.
