error: failed to select a version for `madsim-tokio`.
    ... required by package `risingwave_ctl v0.1.9 (/Users/skyzh/Work/risingwave/src/ctl)`
    ... which satisfies path dependency `risingwave_ctl` (locked to 0.1.9) of package `risingwave_cmd v0.1.9 (/Users/skyzh/Work/risingwave/src/cmd)`
versions that meet the requirements `=0.2.0-alpha.3` (locked to 0.2.0-alpha.3) are: 0.2.0-alpha.3

the package `risingwave_ctl` depends on `madsim-tokio`, with features: `tracing` but `madsim-tokio` does not have these features.

we may see if we can pass this feature flag to tokio.

NetLocalHandle is the entry point of all network operations. However, it should not be sent to other threads. One thread using a handle from other thread would cause it to block forever. The current API design is likely to be misused. For example, users tend to store the handle in a global state. To prevent that, we should either hide this type and make its methods static, or make this type !Send.

https://github.com/huang-jl/madsim-bug/blob/main/src/lib.rs

[ WARN][0.114723s][0.0.0.0:0][madsim_test::tests] Server crash!
[ WARN][5.114723s][0.0.0.0:0][madsim_test::tests] Server restart!
[ INFO][10.114723s][10.0.0.2:1234][madsim_test] Send Incr request from 10.0.0.2:1234 to 10.0.0.1:8000
[ WARN][11.114723s][10.0.0.2:1234][madsim_test] Send incr fail: RPC timeout  <---
[ INFO][11.114723s][10.0.0.2:1234][madsim_test] Send Incr request from 10.0.0.2:1234 to 10.0.0.1:8000
[ INFO][11.124569s][10.0.0.1:8000][madsim_test] Receive increment request, local addr = 10.0.0.1:8000
[ INFO][11.128317s][10.0.0.2:1234][madsim_test] Send incr success

Currently building a server on top of the RPC interface needs a lot boilerplate code:

pub struct Server {...}

impl Server {
    pub fn new() -> Arc<Self> {
        let server = Arc::new(Server {...});
        server.add_rpc_handler();
        server
    }

    // boilerplate!
    fn add_rpc_handler(self: Arc<Self>) {
        let net = NetLocalHandle::current();

        let this = self.clone();
        net.add_rpc_handler(move |req: Ping| {
            let this = this.clone();
            async move { this.ping(req) }
        });
    }

    fn ping(&self, req: Ping) {
        // handle RPC...
    }
}

We hope to provide a procedural macro to make that easy:

#[madsim::service]
impl Server {
    #[ctor]
    pub fn new() -> Arc<Self> {
        Arc::new(Server {...})
    }

    #[rpc]
    fn ping(&self, req: Ping) {
        // handle RPC...
    }
}

Signed-off-by: Runji Wang [email protected]

https://github.com/rust-lang/rust/pull/103594 changed the internal structure of Instant on ARM64 macOS, which breaks the build after nightly-2022-11-19 (roughly) and stable-1.67.

This PR introduces Client::dump() and SimServer::load() function to dump and load etcd data. The data would be dumped in pretty json format, in which bytes are encoded in Rust ascii escape format to make it human-readable.

Example dump data:

{
  "revision": 516,
  "kv": {
    "cf/meta/leader": "\\n\\x0c0.0.0.0:5690",
  },
  "lease": {}
}

This PR adds interceptor support to tonic simulator. It also refactors the internal implementation and fixes passing metadata of tonic request and response.

Added API:

• tonic::{service, Extensions}

https://github.com/rust-lang/rust/pull/102368 (nightly-2022-09-29) changed the memory layout of std::time::{SystemTime, Instant} on Linux (code), making them no longer equal to libc::timespec. So the previous transmute between these types will break data and trigger a panic.

This PR fixes this issue and releases v0.2.9.

https://github.com/madsim-rs/madsim/blob/15e0c805d0c5ea90aa6aca73dc7f27e6497ecb8d/madsim/src/std/net/tcp.rs

        let stream = TcpStream::connect(addr).await.unwrap();
        self.inner
            .setup_connection(self.addr, Some((addr, recver)), stream)
            .await;
        sender

If TcpStream::connect(addr) failed (etc. target is not up), it will unwarp.

Maybe can return an error.

I am trying to simulate several services communicating via madsim RPC and I don't know how to call a service from another service. The Endpoint::call method is applied on an instance of Endpoint but I haven't found a way to get the Endpoint of the current service. See below a small example of what I'm trying to do.

#[derive(Serialize, Deserialize, Request)]
#[rtype("String")]
pub struct HttpGetRequest(pub String);

#[derive(Clone)]
pub struct FrontendService {
    redisAddr: SocketAddr,
}

#[madsim::service]
impl FrontendService {
    pub fn new(redisAddr: SocketAddr) -> Self {
        FrontendService {
            redisAddr,
        }
    }

    #[rpc]
    async fn serve_http_request(&self, req: HttpGetRequest) -> String {
        let reply = <CURRENT_ENDPOINT?>.call(self.redisAddr, redis::GetRedisRequest(req.0.clone())).await.unwrap();
        reply
    }
}

I tried multiple approaches:

• The method server_on consumes the endpoint and Endpoint is not clonable so I can't pass the endpoint after the initial binding.
• The creation of Endpoint from the method Endpoint::connect doesn't work in this context.
• I can't use Arc as the serve_on method consumes an instance of Endpoint.

Is it a supported scenario? If yes how can I do that?

If I can solve this problem, I will submit a PR containing an example of a microservices topology communicating via RPC and running on several simulated nodes. I think this kind of complete example doesn't exist yet in the repo and it would probably save time for future users. Feel free to point me to such an example if it exists.

The main API difference between the two libs is poison detection. Poison detection is useful when panic happens in some thread while others are still runing, but it's not the case in this lib. In a rpc lib, we usually panic when the whole system breaks and can't be recovered, otherwise we should not panic. In another word there's no need to detection mutex poison in madsim.

Apart from poison detection parking_lot locks have better performance in most cases. So switch to parking_lot sync lock is the obvious choice from my view.