* One does not "simply"
* It's not obvious
* It's not really _that_ easily done
* Basically is basically a useless word
* Of course - if you already know how things work you wouldn't be reading the docs
* Clearly is maybe not so clear for everyone
* Just was just a bit harder as there are some uses that are just
* automatic throttle burst size, #24699
* throttleEven used maxBurst=Int.MaxValue, which in practise resulted
in no throttling at all at high rates
* The original problem that throttleEven tried to solve was that when
the throttle rate (cost / per) was high the cost of scheduling
dominated and became much lower than the given rate, if 0 or low
maxBurst was given. Difficult for user to know what maxBurst to use.
* In fact, that was already the case for rates > 30/s.
* This is fixed by automatically adjusting the maxBurst for higher
throttle rates in a new throttle overload that doesn't include
maxBurst parameter
* Also skipped the mode parameter for that variant since Shaping is
what almost always is what you want, and otherwise you can use
the full signature with a good maxBurst
* Deprecated throttleEven, since it is the same. Also fixed the
implementation of throttleEven to use the automatic burst size,
since Int.MaxValue is not useful at all.
* deduplicate logic for IODispatcher #24604
* introduce a resolveDispatcher helper in ActorAttributes
* mention akka.stream.materializer.blocking-io-dispatcher instead of akka.stream.blocking-io-dispatcher in scaladocs
* fix a flaky test
* cosmetic changes in the touched files
* move resolveDispather helper to the Dispatcher companion object under a new name resolve
* filter out mima warning
* fix mima excludes after the 2.5.11 release
* address review comments
* update stream-io.md with the correct dispatcher config key
* mark ActorAttributes.Dispatcher#resolve as internal API
* use the dispatche config key in ActorMaterializer
* add private[akka] to the resolve methods
progressed with cleanup, removing the same thread exec context is
weird... causes issues :-/ Need to debug more, could be that some race
also exists in mapAsync then :\
WIP
finish ask impl via watch stage
mima
consistency spec
fix paradox, and fix adding ask/watch to javadsl source
follow up review
For the current Chunker if the upstream sends larger messages than the
chunk size the buffer can slowly fill up until the app OOMs. Change it
so it only pulls if the buffer is empty
+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
