Tokio TcpStream seems to block

I'm unsure if this is related, but I have a tool that tries to read from a json api every second, but on one armv7 host I'm trying to run that tool my function that connects a TcpStream often blocks the execution for over a minute:

2023-01-06 17:08:47.872621 - swagger_loader - started loading localhost:80/api/v2/robot/capabilities/WifiConfigurationCapability
line without data prefix: : sse-keep-alive
...
line without data prefix: : sse-keep-alive
2023-01-06 17:09:50.973742 - swagger_loader - opened TcpStream

I'm unsure what could cause that. Could specifying the "IP:port" &str address in another way possibly help?

(I split this into a new thread as the thread you replied to was 7 years old and didn't use async.)

1 Like

You could probably start by grabbing a packet capture (tcpdump, Wireshark, etc.) to analyze whether the remote host or the network is at fault. (edit: I see that your logs show localhost, which means your local resolver could be at fault. The network or remote DNS server may not be involved.)

If host resolution takes too long, for instance, you can work around it by just not using hostnames. But I suspect a better solution involves understanding the underlying problem.

1 Like

ah you're right, I didn't even notice... I'll try replace that localhost by 127.0.0.1 and see if that speed's it up.

UPDATE: yes, replacing localhost:80 by 127.0.0.1:80 as the argument to the TcpStream::connect(&str) call worked magic, no more performance problems. Really strange thing I didn't expect, that resolving that name could cause such a huge delay on any system.

btw., if anybody has any suggestions for me, how I could improve the readability / elegance of my project's code, I'm all ears: src/main.rs · main · thomas351 / rust-influxdb-udp-logger · GitLab