craftytrickster/stubborn-io

io traits/structs for tokio that automatically recover from potential disconnections/interruptions

stubborn-io's Issues

Error/Info messages don't show the peer

It would be useful to have the error/info messages show the peer's information in the message to help diagnostics.

Something like:

[INFO] - Will re-perform initial connect attempt #1 to 127.0.0.1:5555 in 5s.

Thank you for this excellent crate!

Share codepaths with poll_(write|flush|write_vectored)

The aforementioned methods are copied and pasted and share almost the same exact code. It should be slightly refactored to share a single codepath, to avoid potential errors in the future if we have to make updates.

StubbornTcpStream in tokio::task::spawn_blocking > rt::System::new().block_on(async...

Hi, thanks for this handy lib.
I'm using the StubbornTcpStream in a block close to this:

tokio::task::spawn_blocking(move || {
    rt::System::new().block_on(async {
        let mut ro = ReconnectOptions::new();
        ro.exit_if_first_connect_fails = false;
        ro.on_connect_callback = Box::new(connect_done);
        ro.on_disconnect_callback = Box::new(on_disconnect);
        ro.on_connect_fail_callback = Box::new(on_connect_fail);

        let mut stream = StubbornTcpStream::connect_with_options("127.0.0.1:6379", ro)
            .await
            .unwrap();

        let (reader, writer) = stream.split();
        let mut buf_writer = BufWriter::new(writer);
        let mut buf_reader = BufReader::new(reader);

        // rx is mpsc::Receiver
        while let Some(cmd) = rx.recv().await {
           ....
        }
    });
});

and for some reason, if I shutdown the other server sock, the disconnect is not detected and no reconnect attempts seem to happen.
I assume, something is in a blocking state (in the while clause) and I need to do some "event processing" call.
Or is it some issue with the actix-web runtime? Any idea?
Thanks.

StubbornTcpStream allows for non-stubborn I/O via its Deref trait

Invoking methods such as try_read from a StubbornTcpStream, which is possible thanks to the Deref implementation that the StubbornIo struct provides, allows doing I/O while skipping the stubborn I/O logic that this crate provides; namely, handling disconnections and reconnections.

This shortcoming allows for somewhat unexpected behavior when trying to use a TcpStream in parallel, because the try_read and try_write methods are the way to go to have concurrent reads and writes to both halves of the connection without relying on locks. Obviously, Tokio's split and into_split methods aren't really applicable either.