Can you see that
https://riker.rs/messaging/
Riker suggests using Multi-type Messaging
https://riker.rs/messaging/
Riker suggests using Multi-type Messaging
By utilizing Receive<T> and #[actor], complex message handling can be defined clearly and concisely
If I use matching with
if everything is ok
Btw do you use clippy?I use vim editor, I install plug Clippy into vim.
And in the Cargo.toml dependencies only riker and log are necessaryI created config/riker.toml allow Riker print log :))
@zentechnhitran for what i see the symptom is in actor/selection.rs, line 97:
yields Err(()) and is silently ignored. If you have an
We have to find out where this error comes from. Unfortunately, it is a stack of
let _ = child.try_tell(msg.clone(), sender.clone());yields Err(()) and is silently ignored. If you have an
ìnfo!{ block instead of let _ = then you see Err(()).We have to find out where this error comes from. Unfortunately, it is a stack of
Result<(),()> so no error information given. Will dig in
I boiled it down to lib.rs lines 78ff, function
yields Err(()). But i have no clue what is going on here, haha ;)
pub fn take<T>... in branch if self.one_time {
match self.msg.take() {
Some(m) => {
if m.is::<T>() {
Ok(*m.downcast::<T>().unwrap())
} else {
Err(())
}
}
None => Err(()),
}yields Err(()). But i have no clue what is going on here, haha ;)
Type <T> is unit (), but isn't supposed to be String?? I don't get it so far.
just tell when you updated your repo.
Hi folks. I'm new to Rust and am looking for an actor framework. Today I read through the actix and riker documentation. In actix, actors live in a context that may have multiple threads available. What is the relationship between riker actors and threads/processes? I'm currently interested in balancing load on a single multicore machine, not a cluster (yet).
Might
Be mistaken. (This lose-focus-to-send is odd)
also @zentechnhitran I'm also using NATS and riker together. Would be very interested in seeing what you are doing
I want to have an actor continually long-polling a http server (minutes blocking), then publishing a message when it arrives. currently I've got the actor pinging itself to start a new http poll and assume the riker threadpool is big enough for one actor always blocking, but is there a better way?
but maybe it doesn't matter
Has anyone successfully integrated Riker with actix? I'm trying to create an ActorSystem and borrow it into the actix HttpServer::new.data but I'm afraid actix starts up a few threads for it and apparently ActorSystem can't be copied/cloned? Does Riker work across these types of threads or would each http server thread need its own ActorSystem (which would suck considering I need 1-to-1 mapping of an actor to a real world thing)?
Could you.... i mean
Ask pattern https://riker.rs/patterns/
(also I'm very new to Rust so I likely might not be doing things right)
Need to .clone() it?
I think the problem was actix's HttpServer::new() takes in a closure that it runs repeatedly to make like 8 worker threads... and I couldn't figure out how to make the actor.clone() inside that without it trying to move into it and errors popping up about trying to move it and failing. I ended up using a data=web::Data type struct and adding the actor_system as a Mutex::new(actor_system) within it. That let me do a App::new().app_data(data.clone()) ... and that went through just fine. On the actix handler side I just had to lock().unwrap() the mutex and use it.
Now I'm just stuck on trying to figure out why my actor_system.select("/user/foo").unwrap().try_tell(Hello,None) isn't working... I did an actor_system.print_tree() at that spot and it seems to be there in the tree at least.
I'm playing around with riker to build a simple actor system and I've run into an issue with actor persistence
`fn persistence_conf(&self) -> Option<PersistenceConf> {
}`
This is documented in https://riker.rs/persistence/ but doesn't seem to be implemented in the code
I've recently been thinking about the actor pattern as I'm rewriting a backend migrating from using actix/actix web to tokio and warp more directly. My ultimate goal is to comprehend first-hand why the actor pattern is still worthwhile, if indeed it is. I've also wondered why message passing cannot be more simple calls and, as I understand it, be less IO bound. I suppose it's that a benefit of the actor pattern is that inter-component communication can be done over a network in which case having first class Messages (normalized, easier to serialize/deserialize) is helpful. However, is there perhaps a more optimal compromise where components can choose? If two components are local couldn't they communicate with direct calls and upon making a component distributed provide an easy path to converting those calls to Message passes?
actors can still be used with actix-web to, for example, add async behavior to a sync db connection, but they aren't intrinsic to the code
@foamdino i looked at the code and there is some persistance thingy in https://github.com/riker-rs/riker/blob/master/src/system/persist.rs. But it doesn't seem to be exported by the module.
