[BUG] Client sink closes after adding a keepalive value

[Sherif Abdelwahab]

The client sink shuts shown after sending the first keepalive ping. Notice the logs where mqtt client connection is closed.

#[ntex::main]
async fn main() -> std::io::Result<()> {
    std::env::set_var("RUST_LOG", "ntex=trace,ntex_mqtt=trace,client=trace");
    env_logger::init();
    
    // connect to server
    let client = client::MqttConnector::new("127.0.0.1:1883")
        .client_id("user")
        // [BUG] adding a keep a keep alive timeout causes the client to close
        // after first ping
        .keep_alive(1)
        .connect()
        .await
        .unwrap();

    let sink = client.sink();

    let router = client.resource("response", publish_v5);

    ntex::rt::spawn(router.start_default());

    let expire = RtInstant::from_std(
                        Instant::now() + Duration::from_secs(1000));
    delay_until(expire).await;

    sink.close();
    Ok(())
}

Logs:

2021-01-13T00:54:37Z TRACE ntex_codec::framed] attempting to decode a frame
[2021-01-13T00:54:37Z DEBUG ntex_mqtt::v5::client::connection] start mqtt client keep-alive task 1
[2021-01-13T00:54:38Z TRACE ntex_mqtt::v5::client::connection] send ping
[2021-01-13T00:54:38Z TRACE ntex_mqtt::framed] FLUSH and Stop state
[2021-01-13T00:54:38Z TRACE ntex_codec::framed] flushing framed transport
[2021-01-13T00:54:38Z TRACE ntex_mqtt::framed] ready
[2021-01-13T00:54:38Z TRACE ntex_mqtt::framed] Framed flushed, shutdown
[2021-01-13T00:54:38Z TRACE ntex_codec::framed] framed transport flushed and closed
[2021-01-13T00:54:39Z TRACE ntex_mqtt::v5::client::connection] send ping
**[2021-01-13T00:54:39Z DEBUG ntex_mqtt::v5::client::connection] mqtt client connection is closed, stopping keep-alive task**

[Nikolay Kim]

this is not a bug. I guess you use default mqtt5 server, but default it uses "DefaultControlService" as a control plain service, and it did not support ping messages, so server closes connection after first pin.

I released 0.4.7 which add ping and disconnect support to mqtt5 default support service.

[Sherif Abdelwahab]

@fafhrd91 Thank you for promptly looking into that. Actually the bug is in version 0.3.17 (which I was depending on earlier). I updated to 0.4.7 latest version and it is solved now.

It was not because of using the "DefaultControlService", I have my own control service on the server side that responds to clients pings (and works fine with other clients).

Thanks again for looking into it.