Hi! I'm practicing Riker trying to create an event sourcing abstraction, and got a bit blocked trying to decide how to run a future inside a
recv function https://github.com/olanod/riker-es/blob/cqrs/src/entity.rs#L61 I thought ctx.run would run the future already but seems it doesn't and so far the only way I see is doing block_on but I run into the error cannot executeLocalPoolexecutor from within another executor I guess block_on is not meant to be run inside recv? is it because of my #[tokio::test]?
@olanod a potential solution to your problem might be found here in the documentation: https://riker.rs/futures/
I see that when that stuff happens there's the sys_event channel, would subscribing to that get me what I want?
riker-rs/website#46 / riker-rs/website#47 ← fixes example on website to compile.
can somebody explain where ctx comes from, here: https://riker.rs/channels/ https://riker.rs/selection/ ?
The
ActorSystemis the heart of a Riker application, starting several threads when it is created. Create only one instance ofActorSystemper application.
so, if i create the ActorSystem in main(), how do i access it in a different part of the application?
do i have to share a ref? or can i get that somehow "by-name"?
system can be accessed from context using
ctx.system
@leenozara so if i understand you correctly, if i start the
ActorSystem in main() there's no way to get an ActorRef in some disparate part of my application, other than passing an actor or a system, or a reference to those, into that part of the application
within the actor system you have access to any actor references that you provide through endowment and introduction, etc. You also can walk up and down the hierarchy by accessing parents and chilkdren.
There's also
.select on Context and System, which is helpful for interacting with actors through system messages and in some cases user-level messages.
outside of the actor system you don't have
Context, but you are free to pass ActorRef, ActorSystem, etc if you have parts of an application that are not an actor themselves
the reason to do so, is to decouple all the data that we're currently passing around, which, in my youthful zeal, i have, wrongly bundled into a single struct
there's a database connection, a worker mutex, and a search index ref. (among others
my thought was that Searcher would lend itself to easily extract into an actor, but it is, itself deeply bundled with two other datastructures, one of them, the post struct, and the other the database connection, because the post struct doesn't hold all data, that Searcher stores about a page
but, if the
Sender isn't part of the ActorSystem i need to pass around a ref, just like with the database connection, and, in my naïvité, i thought i could avoid that, but knowing the actor's name
and that's just the three actors I've identified so far
i haven't looked into how we compute notifications yes, cuz i was afraid of what I'd find, lol
Hi all! looking for some inspiration :) ... I'm trying to store references to different kinds of entities in a HashMap, since I can not put different ActorRef together because they are generic over the message type I figured I can do a HashMap of BasicActorRef but I'd like to go back to ActorRef from BasicActorRef later on, is it possible? I see there is a
typed function but needs an ExtendedCell as parameter, no idea where to get that, looks like an internal type
@olanod - I had a similar requirement - I just use BasicActorRef and use try_tell - the gotcha is looking out for issue #129. There is a work around there where you just need to be explicit when you send your message type in.
@here - Is there any documentation around how to explicitly manage child actors? I have a scenario where I want to shut down a child actor once its done. Looking at Context.shutdown() or explicitly using a Stop message. Akka has a PoisonPill which would kill the actor once it hit that message in the mailbox. Anything similar? And what are the rules when ActorTerminated system message is sent to the parent? Is this before or after the child is shutdown and removed from the children list?
Hi. are there any examples out there on how to send a message to an actor, and, await it’s response (perhaps, something similar to the one on actix with it’s Ping). I guess if i’m sending a message from an actor, i could include it’s address in the send, and, message a response back. But, what if i’m sending it from
main etc?
oh..i guess i’d use the
ask pattern
if i send a message between two actors (say, add 2 + 2) - in order to handle the response (assuming, i do a send back from the compute actor to the asking actor), would my message necessarily also need to include a id of sorts? Wondering what would happen if i send two messages (2,2) and (3,3) one after the other? would the responses be sent back in order? thanks
@georgemp I haven't confirmed it yet(and perhaps you did already?) but my assumption is that because messages arrive to the letter inbox in order because you send them in order from the same place and from there are handed one by one to the handler, on the way back the same should happen and you would get things in order unless you do some async stuff when processing the messages
@olanod - did you ever find a way to run a future to completion from within an actor's recv method? Just using block_on results in the error
cannot execute
LocalPoolexecutor from within another executor: EnterError
and trying to use the ctx.run() method complains about a lifetime issue as the future that I'm trying to execute is a method on an S3 bucket client from rusoto. Thanks!
Never mind, was implementing it incorrectly. The docs work as expected. The key was using the
move keyword
For anyone else that has this issue, which is generally described as trying to use the Riker actor system within another runtime, you do need the top-level runtime to execute futures. So, when using the Tokio runtime, I needed to get a handle to it via
tokio::runtime::Handle::current() and then pass this handle around to the actor system whenever an actor needed to be able to block on a future. Hope this helps others! I think this should be added to the docs, and if I get motivated I may submit a PR for this.
