We have a nice sample/guide showing distributed workers pulling work rather
than pushing that may be interesting to you:
https://developer.lightbend.com/guides/akka-distributed-workers-scala/
That does however potentially create a bottleneck so if you really want to
avoid that you cannot copy the
To reply about:
> I think the two methods Source.lazily and Flow.lazyInit should be
alligned (in their name and in their materialized values)
No, those are different things and should not be name-aligned. The lazyInit
wording is used to talk about “on first element”,
while we use the lazily to me
Whoa (!), thanks for the great catch.
You are absolutely right that the Flow.lazyInit is incorrect.
It is not possible to get the M strictly from the Future[M] after all.
I skimmed tests and they seem to not verify this;
The Sink version is fine, so at least that.
Could you log a bug about this
I just saw that Source.lazily implements a similar concept:
def lazily[T, M](create: () ⇒ Source[T , M]): Source[T, Future[M]]
Here a the materialized value is a Future that is failed if there was no demand before the source gets never created.
I think the two methods Source.lazily an
In build.sbt:
"com.enragedginger" %% "akka-quartz-scheduler" % akkaQuartz.version
In application.conf:
akka {
quartz {
defaultTimezone = "Europe/Berlin"
schedules {
ReloadDIY {
description ="Reload content every day"
expression = "0 0/5 * * * ?"
}
}
Hi,
studying the newly Flow constructor Flow.lazyInit
def lazyInit[I, O, M](flowFactory: I ⇒ Future[Flow[I, O, M]], fallback: () ⇒ M): Flow[I, O, M]
(cf. https://doc.akka.io/api/akka/2.5.11/akka/stream/scaladsl/Flow$.html) I wondered how (citation from ScalaDoc)
The materialized v
