Hello,
I am trying to use AKKA routers in my application. This is my first time to
try to use touting.
The problem is that I want to have the messages to be routed based on the
routing logic (hashing in the case of my app) and others to be broadcated
to all routees.
Is there a way to create a r
I think this is what you're after:
https://doc.akka.io/docs/akka/current/routing.html#broadcast-messages
If you want to hide the decision logic from the sender, you can create a
custom actor that inspects the message and /either/ sends it to the
hashing router as-is /or /sends it wrapped in a
Thank you very much, Michal.
This is exactly what I was looking for.
Best,
Iman
On Tuesday, March 6, 2018 at 4:22:55 PM UTC+1, Michal Borowiecki wrote:
>
> I think this is what you're after:
>
> https://doc.akka.io/docs/akka/current/routing.html#broadcast-messages
>
> If you want to hide the deci
The Akka HTTP documentation [1] says:
"The Http.ServerBinding also provides a way to get a hold of the actual
local address of the bound socket, which is useful for example when
binding to port zero (and thus letting the OS pick an available port)."
The scenario is I'm using a localhost http
I have noticed an issue where if a future maps/flatmaps after actor
shutdown, a NullPointerException is thrown. I've narrowed it down to the import
context.dispatcher, which I technically understand since that is closing
over actor state. If I change that to implicit val ec = context.dispatcher,
Context is bound to the lifecycle of the actor.
On Tue, Mar 6, 2018 at 8:37 PM, Jeff wrote:
> I have noticed an issue where if a future maps/flatmaps after actor
> shutdown, a NullPointerException is thrown. I've narrowed it down to the
> import
> context.dispatcher, which I technically underst
I suspected as much. So what would you suggest as for handling use cases
where you could have chained flatmaps on futures that at the end will
pipeTo a message back to the actor. Should we set the ExecutionContext to a
val?
On Tuesday, March 6, 2018 at 12:09:22 PM UTC-8, √ wrote:
>
> Context i
What do you mean?
Binding is not any different if you use high / low level DSLs (that’s the
routing DSL vs. just matching incoming objects).
The difference is in the binding call you can do, there’s a few styles, yet
each gives back a binding, which contains an address:
val bindingFuture = Http()
Hi Dolly,
There's something I don't understand from your requirements - do you want
to delay messages and only push them based on the timer?
If you don't need the timer, a simpler implementation could be something
like this:
onPush:
save element
pull
if pulled, push the event
onPull:
if
