leonhartley / coerce-rs Goto Github PK

View Code? Open in Web Editor NEW

701.0 15.0 21.0 1.74 MB

Actor runtime and distributed systems framework for Rust

Rust 100.00%

rust async-await async actor-model actors tokio-rs await distributed remote cluster

coerce-rs's People

Contributors

Stargazers

Watchers

coerce-rs's Issues

message not received by Actor when LocalActorRef::notify is used

Hi,
I need to send a message to an actor in a non-async function because a struct from an external crate that I use does not implement Send.

From the signature, it looks like I could use LocalActorRef::notify for that and the code compiles with it but the message never reaches the actor.

I cannot share the actual code but it looks something like this:

impl Handler<StartMessage> for Actor1 {
    async fn handle(
        &mut self,
        _message: StartMessage,
        _ctx: &mut ActorContext,
    ) -> Result<(), String> {
        let ui_actor_ref = self.actor2_ref.clone();
        tokio::spawn(async move { start(actor2_ref) });
        Ok(())
    }
}

 fn start(
    actor2_ref: LocalActorRef<Actor2>,
) -> Result<(), String> {
        // dose some other stuff
        actor2_ref
            .notify(StatusEvent {
                event_type: StatusEventTypes::Progress,
                payload: status.to_string(),
                )
                .unwrap(),
            })
            .unwrap();
}

Do I misunderstand notify?
Is there another blocking way to send messages to Actors?

Infinite reconnect attempt loop, preventing shard rebalancing

Steps to reproduce:

run two instances of the sharded chat server example, with redis
connect one client to each and create a room (so there are two shards present in the whole system)
ctrl+c one of the nodes

Now, the system that is still running will enter an infinite reconnect loop, instead of firing a Forget so that the shards can be rebalanced. The loop is between the Connect and Disconnect events on the RemoteClient handle. I think it makes sense to introduce a Retry in a config somewhere and Forget it after n retries.

Also, stopping the second node and subsequently starting it gets the system into a correct state again, where the node picks up both shards from redis, and then starting a second node rebalances correctly as well.

Awesome library btw :) excited to see more

[Devops] Can Coerce-rs support 10000 node(remote actor) network?

Hi,

I am developing a blockchain layer2 network. The network nodes are permissionless, and the number of nodes may reach 10,000. Each node is a proxy (gateway) using the remote actor in Coerce-rs, and nodes communicate through remote actors。 The network between nodes is not high-speed network, does Coerce-rs support such a network?

Regards
by lshoo

Request: Supervision Strategies / Agent Restart Behaviors

It's possible I've missed this, but I haven't been able to figure out how a supervised actor (one that is spawned by another) might be restarted, in the event of a failure case.

Remove the dependence to async-trait

Any idea to upgrade to rust-1.7.5 and remove the dependence to async-trait?

Toggle unstable `tracing/valuable` support with a feature flag

Since the requirement of enabling tracing/valuable is impeding adoption of newer versions of this library, we should move tracing Valuable integration to a feature flag to remove the requirement of setting the tracing_unstable compiler flag among other things.

This should make it easy to get going with Coerce!

Coerce performance

I ran benchmarks provided in coerce crate on my 5950x and got this

    Running benches/actor_creation.rs (/home/pranay/scratch/wd/Coerce-rs/target/release/deps/actor_creation-27b48128a604a745)

running 1 test
test create_1000_actors ... bench:   6,488,134 ns/iter (+/- 3,843,611)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured

     Running benches/actor_messaging.rs (/home/pranay/scratch/wd/Coerce-rs/target/release/deps/actor_messaging-0aba58e833c97004)

running 2 tests
test actor_notify_1000_benchmark ... bench:     151,532 ns/iter (+/- 136,179)
test actor_send_1000_benchmark   ... bench:   4,892,811 ns/iter (+/- 3,425,463)

Quite surprised that it takes so much time. I am trying to build a social network where each post can be an orderbook, so a lot of orderbooks. I liked Coerce's API compared to something like Bastion, but this benchmark surprised me. Is this going to be representative latencies in the final web server or is this just happening because we are awaiting one after the other on a multi-threaded runtime, and Tokio is wasting too much time in the scheduler doing nothing useful at all?

Great library

Just wanted to say thanks for the great library. It is neatly designed, I tested around 2 other libraries (Zester, puppet), in which this one had the right balance.

It had a nice api to use via rust trait handlers as opposed to writing event loop.
Sufficiently feature complete.
The Actor trait has lifestyle methods I could use to hook in custom stuffs.

Few comments:

At a glance the naming is bit confusing as to what the project is about.
Any plans to support async trait as in https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.html ?

Production. Actix.

Hey there, I am coming from actix actors background, Suffering from some limitations, and I on search for an alternative or an easy convert.

I am going to state down my use case, and I wonder if it will be feasible to make the convert upon your answers. It is also good to know if the crate is being used on production.

Websocket actor, handle read/write. With actix simple as ctx.addStream(), then implement the message types, for write add write part of the stream to the sate of the actor, and calling when needed.
Db actor, handle db operations. here comes majore suffering with async/await/blocking thread ..etc, will share a snippets at the end.
Also using tauri, so the runtime enviroment has to be shared, where as had a blummer back in while to figure actix runtime fix to make it work, which is still not compelling.
some cpu intensive actors dealing with file system on seperate threads.
back to 4 where as cross actor comunication through recipients or actor refs.

Not going to mention supervisoring as I already read that it is there.
Making the move to an already crate or using pure rust / tokio channels is the way to go for this project of mine, but knwoing a crate already has the potentials to solve the issues am facing will just make things easier, It will come at the end how much time the conversion of the project will take. So your answers are really important.

Thank you.

Blocking thread. // lack of async/await support.
I also tried atomicResponse but in that case I losse access to self, and being static issues.
Not trying to figure out a fix, as moving forward async/await is the future to go.

impl Handler<DbOperations> for McActor {
    type Result = String;
    //type Result = ResponseFuture<String>;
    fn handle(&mut self, msg: DbOperations, ctx: &mut Self::Context) -> Self::Result {
        return match msg {
             DbOperations::Get { key } => {
               block_on(async {
                    sqlx::query_as::<_, DbOperationValues>(select_query)
                        .bind(key)
                        .fetch_one(self.db.as_ref().unwrap())
                        .await
                        .unwrap()
                }).value
                 
            }
            DbOperations::Set { key, value } => {   
                block_on(async {
                    sqlx::query_as::<_, DbOperationValues>(insert_query)
                        .bind(key)
                        .bind(value)
                        .fetch_one(self.db.as_ref().unwrap())
                        .await
                        .unwrap()
                }).value
            }
        };
    }
}

new version release?

seems the latest version was released in Oct 2023. there have been tons of updates since then. any plans to cut a new release anytime soon?

Nested panicking on missing actor

I have a simple test to start up and stop my system. At one point, I started getting thread panicked while panicking. aborting. error. I tracked it back to me forgetting to register one of factories for sharding with .with_actor. Not sure if this is worth even pursuing but a nicer error message would probably be a good idea 😄

Trace logs here but they don't seem very related

is there any way to create custom Actor traits that are object safe ?

I would like to define a custom actor trait like the following :

pub trait StorageActor : Handler<WriteData> + Handler<ReadData> {}

However when trying to use a LocalActorRef<StorageActor> I get

size for values of type `(dyn StorageActor + 'static)` cannot be known at compilation time
the trait `Sized` is not implemented for `(dyn StorageActor + 'static)`

I'm still fairly new to rust, and after reading https://huonw.github.io/blog/2015/01/object-safety/ I still don't fully understand what the specific blocker is. - could it be in the Actor trait fn actor_ref(&self, ctx: &ActorContext) -> LocalActorRef<Self> which seems to match up to the link under References Self - There’s two fundamental ways in which this can happen, as an argument or as a return value

Cheers

Cameron

Checking message transmissibility at compile time

Would it make sense to create a trait with something like RemoteMessage: Message, and move the into_remote_envelope and into_remote_envelopeinto it? Currently it just defaults to Err(NotTransmissible) which is not great and throws an error at runtime. Doing this would allow changing with_handler<A: Actor, M: Message> into with_handler<A: Actor, M: RemoteMessage>, which would alert user about this at compile time.

Use of coerce-rs in production

Hello! What is the production-readiness status of this project? Are you aware of any people or companies that run systems that leverage this library in production? Thank you.

How to get the sender of a message?

In the scenario I'm working on, whenever a Worker joins the cluster, it sends a message with some information to the Manager. This Manager needs to store the address of the Worker who sent the message to send messages later. However, it was not clear in the documentation how to do this.

Request: Update dependency for Syn to 2.x

Hello. Unless there is a need to keep it on the 1.x line, it would be good to have the dependency updated. I can submit a PR if there is interest. Thanks!

help with example

I am having an issue with running examples/coerce-cluster-example

I am doing the following

git clone ...
in one terminal run cargo run --package coerce-cluster-example --bin coerce-cluster-example which runs fine and doesn't log anything
in another terminal run cargo run --package coerce-cluster-example --bin worker which errors :

     Running `target/debug/worker`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Serialisation(NotTransmittable)', examples/coerce-cluster-example/src/worker.rs:59:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

running the worker a few times either results in the above or alternatively :

thread 'main' panicked at 'unable to get echo actor', examples/coerce-cluster-example/src/worker.rs:56:14

here's a backtrace for the later

thread 'main' panicked at 'unable to get echo actor', examples/coerce-cluster-example/src/worker.rs:56:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
   2: core::panicking::panic_display
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:139:5
   3: core::panicking::panic_str
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:123:5
   4: core::option::expect_failed
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/option.rs:1879:5
   5: core::option::Option<T>::expect
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/option.rs:741:21
   6: worker::main::{{closure}}
             at ./examples/coerce-cluster-example/src/worker.rs:53:21
   7: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/future/mod.rs:91:19
   8: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/park.rs:283:63
   9: tokio::runtime::coop::with_budget
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/coop.rs:102:5
  10: tokio::runtime::coop::budget
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/coop.rs:68:5
  11: tokio::runtime::park::CachedParkThread::block_on
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/park.rs:283:31
  12: tokio::runtime::context::BlockingRegionGuard::block_on
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/context.rs:295:13
  13: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/scheduler/multi_thread/mod.rs:66:9
  14: tokio::runtime::runtime::Runtime::block_on
             at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/runtime.rs:284:45
  15: worker::main
             at ./examples/coerce-cluster-example/src/worker.rs:62:5
  16: core::ops::function::FnOnce::call_once
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:251:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

and one for the former error

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Serialisation(NotTransmittable)', examples/coerce-cluster-example/src/worker.rs:59:27
stack backtrace:
   0:     0x561f0b600250 - std::backtrace_rs::backtrace::libunwind::trace::he615646ea344481f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x561f0b600250 - std::backtrace_rs::backtrace::trace_unsynchronized::h6ea8eaac68705b9c
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x561f0b600250 - std::sys_common::backtrace::_print_fmt::h7ac486a935ce0bf7
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x561f0b600250 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1b5a095d3db2e28f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x561f0b6228be - core::fmt::write::h445545b92224a1cd
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/fmt/mod.rs:1209:17
   5:     0x561f0b5fb365 - std::io::Write::write_fmt::h55a43474c6520b00
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/io/mod.rs:1682:15
   6:     0x561f0b600015 - std::sys_common::backtrace::_print::h65d20526fdb736b0
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:47:5
   7:     0x561f0b600015 - std::sys_common::backtrace::print::h6555fbe12a1cc41b
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:34:9
   8:     0x561f0b60189f - std::panicking::default_hook::{{closure}}::hbdf58083140e7ac6
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:267:22
   9:     0x561f0b6015da - std::panicking::default_hook::haef8271c56b74d85
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:286:9
  10:     0x561f0b601f98 - std::panicking::rust_panic_with_hook::hfd45b6b6c12d9fa5
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:688:13
  11:     0x561f0b601d37 - std::panicking::begin_panic_handler::{{closure}}::hf591e8609a75bd4b
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:579:13
  12:     0x561f0b6006fc - std::sys_common::backtrace::__rust_end_short_backtrace::h81899558795e4ff7
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:137:18
  13:     0x561f0b601a52 - rust_begin_unwind
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
  14:     0x561f0ab40603 - core::panicking::panic_fmt::h4235fa9b4675b332
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
  15:     0x561f0ab408c3 - core::result::unwrap_failed::ha17dbf463031a5e1
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1791:5
  16:     0x561f0ab5990a - core::result::Result<T,E>::unwrap::h77d58a0b07e41725
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1113:23
  17:     0x561f0acb4140 - worker::main::{{closure}}::h9aef3f54187918ed
                               at /workspace/Coerce-rs/examples/coerce-cluster-example/src/worker.rs:59:20
  18:     0x561f0aca0b6c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7e820c479da0c931
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/future/mod.rs:91:19
  19:     0x561f0ac28f00 - tokio::runtime::park::CachedParkThread::block_on::{{closure}}::h37062d27951f96ee
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/park.rs:283:63
  20:     0x561f0ac28895 - tokio::runtime::coop::with_budget::h667576cc87ecb351
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/coop.rs:102:5
  21:     0x561f0ac28895 - tokio::runtime::coop::budget::h55c7487ad9871f6c
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/coop.rs:68:5
  22:     0x561f0ac28895 - tokio::runtime::park::CachedParkThread::block_on::h99a02ad746356d5b
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/park.rs:283:31
  23:     0x561f0abf9350 - tokio::runtime::context::BlockingRegionGuard::block_on::h0033b04aaa52f1cc
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/context.rs:295:13
  24:     0x561f0ac96cb0 - tokio::runtime::scheduler::multi_thread::MultiThread::block_on::h0abd54cdde5d5b80
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/scheduler/multi_thread/mod.rs:66:9
  25:     0x561f0ac9792e - tokio::runtime::runtime::Runtime::block_on::h55beae8d4b8413c7
                               at /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.23.0/src/runtime/runtime.rs:284:45
  26:     0x561f0ac56b09 - worker::main::ha19a9c6daaa193dd
                               at /workspace/Coerce-rs/examples/coerce-cluster-example/src/worker.rs:62:5
  27:     0x561f0ab5bc7b - core::ops::function::FnOnce::call_once::hb6c9664bbfe19beb
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:251:5
  28:     0x561f0acb33ae - std::sys_common::backtrace::__rust_begin_short_backtrace::h07e129be76c7d72f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:121:18
  29:     0x561f0acb4f71 - std::rt::lang_start::{{closure}}::h7f6c2585d7162f42
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:166:18
  30:     0x561f0b5f7edb - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h072eb4cd8da964ba
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286:13
  31:     0x561f0b5f7edb - std::panicking::try::do_call::h8eca204fe9266946
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
  32:     0x561f0b5f7edb - std::panicking::try::h12574e1b7b2cbacb
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
  33:     0x561f0b5f7edb - std::panic::catch_unwind::hf71522d4448329d6
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
  34:     0x561f0b5f7edb - std::rt::lang_start_internal::{{closure}}::h65b66ac9bff580f8
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:48
  35:     0x561f0b5f7edb - std::panicking::try::do_call::hfff61e33ca3db9f1
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
  36:     0x561f0b5f7edb - std::panicking::try::he48c8ecead279cad
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
  37:     0x561f0b5f7edb - std::panic::catch_unwind::hd510a26bfc950ccc
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
  38:     0x561f0b5f7edb - std::rt::lang_start_internal::hc680b25eab888da9
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:20
  39:     0x561f0acb4f4a - std::rt::lang_start::he0d1ffad91d65456
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:165:17
  40:     0x561f0ac56bbe - main
  41:     0x7f918c3c6d90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  42:     0x7f918c3c6e40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  43:     0x561f0ab40aa5 - _start
  44:                0x0 - <unknown>

Unable to build with 0.8.10

Hey,

I'm using latest coerce version, but I'm getting a build error:

error[E0425]: cannot find value VERSION_3_2_0 in crate protobuf --> /home/xxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/coerce-0.8.10/src/remote/net/proto/network.rs:26:49 | 26 | const _PROTOBUF_VERSION_CHECK: () = ::protobuf::VERSION_3_2_0; | ^^^^^^^^^^^^^ help: a constant with a similar name exists: VERSION_3_3_0 | | 7 | pub const VERSION_3_3_0: () = (); | --------------------------- similarly named constant VERSION_3_3_0 defined here

I tried checking if I had any other dependency on protobuf 3.3.0 but it looks like it comes from coerce if I do cargo tree

Dropping `coerce::actor::scheduler::timer::Timer` does not stop him.

The timer continues if the handle is dropped. Is this intended behavior?
Also why is the timer intentionally made drifting?

See: https://github.com/LeonHartley/Coerce-rs/blob/master/coerce/src/actor/scheduler/timer.rs#L93

after running 'cargo update' I get a compile error in coerce : `actors::GetAll: IntoParams` is not satisfied

error[E0277]: the trait bound `actors::GetAll: IntoParams` is not satisfied
  --> /home/cameronbraid/.cargo/registry/src/index.crates.io-6f17d22bba15001f/coerce-0.8.10/src/remote/api/system/actors.rs:89:27
   |
89 |     Query(options): Query<GetAll>,
   |                           ^^^^^^ the trait `IntoParams` is not implemented for `actors::GetAll`

I'm using deps :

workspace

coerce = "0.8"
coerce-macros = "0.2"

crate:

coerce = { workspace = true, features = [
    "remote",
    "persistence",
    "metrics",
    "sharding",
    "api",
    "actor-tracing",
    "actor-tracing-debug",
    "client-auth-jwt",
] }
coerce-macros = { workspace = true }

Failing to compile coerce in library

I'm trying out the coerce library (full features) in a library I'm playing with, but I'm failing to compile coerce v0.8.5. I'm able to compile and run tests (--all-features) in the coerce library itself; however I can't build coerce v0.8.5 as a dependency in my library. I've matched all of the dependencies (and versions) with coerce. I appreciate any suggestions to clear the issue. My project can be found at: https://github.com/dmrolfs/coerce-cqrs-rs

The errors I get pertain to an unsatisfied trait bound valuable::Value<'_>: tracing::Value:

$ cargo c
    ...
    Checking coerce v0.8.5

error[E0277]: the trait bound `valuable::Value<'_>: tracing::Value` is not satisfied
  --> /Users/rolfs/.cargo/registry/src/github.com-1ecc6299db9ec823/coerce-0.8.5/src/actor/lifecycle.rs:88:28
   |
88 |                   let span = tracing::info_span!(
   |  ____________________________^
89 | |                     "actor.recv",
90 | |                     ctx = log.as_value(),
91 | |                     message_type = msg.name(),
92 | |                 );
   | |_________________^ the trait `tracing::Value` is not implemented for `valuable::Value<'_>`
   |
   = help: the following other types implement trait `tracing::Value`:
             &'a T
             &'a mut T
             (dyn StdError + 'static)
             (dyn StdError + Sync + 'static)
             (dyn StdError + std::marker::Send + 'static)
             (dyn StdError + std::marker::Send + Sync + 'static)
             Arguments<'a>
             Box<T>
           and 34 others
   = note: required for the cast from `valuable::Value<'_>` to the object type `dyn tracing::Value`
   = note: this error originates in the macro `$crate::valueset` which comes from the expansion of the macro `tracing::info_span` (in Nightly builds, run with -Z macro-backtrace for more info)

LICENSE

@LeonHartley - what is license of this project ? Based on the Cargo.toml it is Apache-2.0 but I'd like to confirm that this is valid for the whole source code ?

[Test] Test error

I got errors when I run cargo test:

running 3 tests
test test_redis_journal_actor_integration ... ok
test test_redis_journal_read_write_snapshot ... FAILED
test test_redis_journal_read_write_messages ... FAILED

or cargo nextest run --workspace:

        PASS [   0.027s] coerce::test_remote_sharding test_shard_coordinator_shard_allocation
        PASS [   0.035s] coerce::test_remote_actor_creation test_remote_actor_deploy_remotely
        PASS [   0.056s] coerce::test_actor_supervision test_actor_child_spawn_and_stop
        PASS [   0.530s] coerce::test_remote_sharding_rebalancing test_shard_rebalancing_upon_node_termination
        PASS [   2.011s] coerce::test_remote_system_health test_heartbeat_actor_monitoring
------------
     Summary [   2.035s] 38/47 tests run: 31 passed, 7 failed, 0 skipped
        FAIL [   0.016s] coerce::test_remote_actor_err test_remote_actor_err
        FAIL [   0.019s] coerce::test_remote_actor_locate test_remote_actor_locate_remotely
        FAIL [   0.018s] coerce::test_remote_api test_remote_api_routes
        FAIL [   0.027s] coerce::test_remote_cluster_formation test_remote_cluster_workers
        FAIL [   0.025s] coerce::test_remote_cluster_heartbeat test_remote_cluster_heartbeat
        FAIL [   0.019s] coerce::test_remote_pubsub test_pubsub_distributed
        FAIL [   0.014s] coerce::test_remote_sharding test_shard_host_actor_request

How to fix or config for these errors?
I clone the main branch, the os is wsl2 + ubuntu 22.04, rust version is 1.68.2.

Thanks

Error compiling the project

I'm getting an error when trying to compile coerce:

error[E0277]: the trait bound `valuable::Value<'_>: tracing::Value` is not satisfied
  --> /github/home/.cargo/registry/src/github.com-1ecc6299db9ec823/coerce-0.8.9/src/actor/lifecycle.rs:84:28
   |
84 |                   let span = tracing::info_span!(
   |  ____________________________^
85 | |                     "actor.recv",
86 | |                     ctx = log.as_value(),
87 | |                     message_type = msg.name(),
88 | |                 );
   | |_________________^ the trait `tracing::Value` is not implemented for `valuable::Value<'_>`

And a bunch of other similar issues.

Is this related to tracing package version perhaps?

These are relevant packages in Cargo.toml:

tracing = "0.1"
coerce = { version = "0.8.9", features = ["full"] }
coerce-macros = "0.2.0"

Thanks

Actor stops receiving messages after a panic

If a panic occurs in an actor message handler, that actor stops receiving the message, and is only returning this error:

failed to send message, ref is no longer valid

Are there any extra steps needed to make sure the supervisor is running and can restart the actor in these cases?

Thanks

Get Remote Actor fail

When I run the distribute example, the worker sometimes can not get the remote actor.
It seems that the registry return Ok but with Nothing(None):

received actor node (current_node=example-worker, actor_id=echo-actxor, actor_node=None)

        match self
            .inner
            .registry_ref
            .send(GetActorNode {
                actor_id: actor_id.clone(),
                sender: tx,
            })
            .await
        {
            Ok(_) => {
                // TODO: configurable timeouts (?)
                match tokio::time::timeout(tokio::time::Duration::from_secs(5), rx).await {
                    Ok(Ok(res)) => {
                        trace!(
                            "received actor node (current_node={}, actor_id={}, actor_node={:?})",
                            self.node_tag(),
                            &actor_id,
                            &res
                        ); 
                        res

package conflict - consider upgrading utoipa

 --> /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/coerce-0.8.3/src/remote/api/system/mod.rs:35:76
    |
35  |             .merge(SwaggerUi::new("/swagger").url("/api-doc/openapi.json", ApiDoc::openapi()))
    |                                               ---                          ^^^^^^^^^^^^^^^^^ expected struct `utoipa::openapi::OpenApi`, found a different struct `utoipa::openapi::OpenApi`
    |                                               |
    |                                               arguments to this function are incorrect
    |
    = note: struct `utoipa::openapi::OpenApi` and struct `utoipa::openapi::OpenApi` have similar names, but are actually distinct types
note: struct `utoipa::openapi::OpenApi` is defined in crate `utoipa`
   --> /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/utoipa-2.4.2/src/openapi.rs:36:1
    |
36  | / builder! {
37  | |     /// # Examples
38  | |     ///
39  | |     /// Create [`OpenApi`] using [`OpenApiBuilder`].
...   |
114 | |     }
115 | | }
    | |_^
note: struct `utoipa::openapi::OpenApi` is defined in crate `utoipa`
   --> /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/utoipa-3.0.1/src/openapi.rs:37:1
    |
37  | / builder! {
38  | |     /// # Examples
39  | |     ///
40  | |     /// Create [`OpenApi`] using [`OpenApiBuilder`].
...   |
115 | |     }
116 | | }
    | |_^
    = note: perhaps two different versions of crate `utoipa` are being used?
note: associated function defined here
   --> /home/cameronbraid/.cargo/registry/src/github.com-1ecc6299db9ec823/utoipa-swagger-ui-3.0.2/src/lib.rs:226:12
    |
226 |     pub fn url<U: Into<Url<'static>>>(mut self, url: U, openapi: OpenApi) -> Self {
    |            ^^^
    = note: this error originates in the macro `builder` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.
error: could not compile `coerce` due to previous error

if I point cargo at my locally checked out coerce with utoipa upgraded to version 3 this goes away - is that the correct fix ?

Add examples

This crate could use some examples to showcase its features

How does Corece handle CPU-bound operations?

I am migrating my project from actix to coerce and I have a question about how CPU-bound tasks are managed. The example below shows the actix code to perform the fibonacci operation on 3 Arbiters. An arbiter is a single-threaded event loop that runs one or more actors. In this way, although the event loop is blocked by the fibonacci calculation, it is possible to perform 3 calculations in parallel.

#[actix::main]
async fn main() {
    let start = Instant::now();
    let a1 = Arbiter::new().handle();
    let a2 = Arbiter::new().handle();
    let a3 = Arbiter::new().handle();

    let addr1 = Calculator::start_in_arbiter(&a1, |_ctx| Calculator);
    let addr2 = Calculator::start_in_arbiter(&a2, |_ctx| Calculator);
    let addr3 = Calculator::start_in_arbiter(&a3, |_ctx| Calculator);

    let fib_future1 = addr1.send(Fibonacci(43));
    let fib_future2 = addr2.send(Fibonacci(43));
    let fib_future3 = addr3.send(Fibonacci(43));

    let futures = vec![fib_future1, fib_future2, fib_future3];

    let results = join_all(futures).await;

    for (i, result) in results.iter().enumerate() {
        match result {
            Ok(value) => println!("Resultado {}: {}", i + 1, value),
            Err(e) => println!("Erro ao receber o resultado {}: {:?}", i + 1, e),
        }
    }

    let duration = start.elapsed();
    println!("Tempo decorrido: {:?}", duration);
}

How does Coerce work under the hood? I couldn't find anything about it in the documentation. How to perform 3 CPU-bound tasks in parallel as in the example?

Cannot clone Receiver, nor notify

Hi Leon,

My team and I are investigating moving over from Actix to Coerce, well done, it's a very nice implementation, but I've found a couple of things that may make it hard for us, maybe I'm not looking at the code properly, so please correct me if I'm wrong.

I cannot clone a Receiver. Is this on purpose, or would you consider a pull request that implements this?
I cannot call notify or scheduled_notify a receiver. We use this a bit in our current code base, so again, if you're happy to include this, i'll gladly implement and send a pull request.

Cheers,
Adriaan Prinsloo

How to use tracing with coerce-rs?

How can we setup the tracing crate with the actors? Can we get the proper propagation of spawns to actors?

leonhartley / coerce-rs Goto Github PK

coerce-rs's People

Contributors

Stargazers

Watchers

Forkers

coerce-rs's Issues

Recommend Projects

Recommend Topics

Recommend Org