KubeMQ
Client SDKsRustHow-to guidesConnection

Ping

Send a ping to verify KubeMQ connectivity and read server information using the Rust SDK.

Overview

A ping is a lightweight liveness check — you call it to confirm the broker is actually reachable before sending real traffic, without standing up a publisher, subscriber, or queue client just to find out. It's the tool of choice for startup readiness checks, container liveness/readiness probes, and connection-health dashboards that need a fast, cheap go/no-go signal.

client.ping().await issues a minimal RPC to the server and returns a ServerInfo (host, version, uptime) confirming the broker answered. It works over the same connection regardless of which messaging pattern you use elsewhere on that client — events, queues, commands, or queries.

Gotchas: a failed ping() doesn't close the client — the SDK's reconnect logic keeps retrying in the background, so handle the returned Result yourself rather than assume the client tears itself down. A successful ping only confirms the broker process answered, not that a specific channel or queue exists or has capacity. It also bypasses authentication and succeeds even without an auth token configured — don't rely on it to validate credentials, only reachability.

Prerequisites

  • KubeMQ server running on localhost:50000
  • Rust SDK installed (cargo add kubemq)

Code

main.rs
use kubemq::prelude::*;

#[tokio::main]
async fn main() -> kubemq::Result<()> {
    let client = KubemqClient::builder()
        .host("localhost")
        .port(50000)
        .build()
        .await?;

    let info = client.ping().await?;
    println!("Server host: {}", info.host);
    println!("Server version: {}", info.version);
    println!("Server start time: {}", info.server_start_time);
    println!("Server uptime (seconds): {}", info.server_up_time_seconds);

    client.close().await?;
    Ok(())
}

How It Works

  • ping() bypasses authentication and can be called even without an auth token configured.
  • Returns ServerInfo with host, version, start time, and uptime.
  • Review timeouts, channel names, and client IDs before running against shared environments.
  • Run the program while the server from the prerequisites is available.

Was this page helpful?

On this page