-
Notifications
You must be signed in to change notification settings - Fork 62
HttpResponseTooShort for first request after a while #79
Comments
Sounds like a connection reuse issue after timeout. #80 possibly related? |
I agree, it sounds like we're failing to detect that the socket has died. When we do the From http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html
|
I'm glad it looks like the issue is known. What would be the timeline for a fix? |
This week. |
What is the status on this? |
No update. I've had it as an open tab for 8 weeks. It's near the top of my TODO list. Sorry. |
Thanks! No need to say sorry :D |
I checked out the branch that this PR uses and use it in my Cargo.toml:
Unfortunately, I still get the error message: EDIT: I just noticed it got merged to master branch, but it seems to be needing some more investigation. |
Damn. We haven't merged it yet (but we will, since I've run into the issue that it fixes). Frustrating that it doesn't fix your issue. Are you able to use |
Well I decided to just stop reusing clients for now as there is no requirement for me to do so. I don't have the skills to use tcpdump to find out more, sorry. |
…he socket 5b7b23c simple_http: if writing fails, try reconnecting the socket (once) (Andrew Poelstra) 1d11885 simple_http: rename writeable version of `sock` to `write_sock` (Andrew Poelstra) cfc4e6f simple_http: abstract socket recreation into `fresh_socket` method (Andrew Poelstra) Pull request description: Attempt at #79. Does not fix the issue, but will merge this anyway since it fixes an issue I've hit in other projects. ACKs for top commit: tcharding: ACK 5b7b23c Tree-SHA512: ab1384463f9d5493d2cb47ed1b09775d6e89db702e5ab1e8c18d99f264bb3c140022b4a8402db664e68a082ef32dcaf498abb96f0a9a27892e67b21a5bb6cef8
0de1c58 simple_http: unit test to demonstrate detecting broken pipe (Philip Robinson) 0cab08a simple_http: add second send attempt if read indicates socket is broken (Philip Robinson) Pull request description: While upgrading from v0.11 to v0.14 I noticed that I started getting the following error when the server had disconnected the socket between requests, in our case due to the server idle timeout: ``` Err(Transport(HttpResponseTooShort { actual: 0, needed: 12 })) ``` The same issue as is reported in #79 I believe. I noticed #84 was an attempt to solve the problem and I think I found out why it didn't work as expected. The client is using a `BufWriter` to write the `TcpStream` and unless you flush the buffer you will not see the broken pipe error in time in order to request a fresh connection. This PR adds in the flushes and provides a unit test demonstrating that it fixes the issue. If you comment out the flushes you will see the symptom reported in #79. ## Revision The first approach of flushing the write buffer twice during the POST angered HTTP servers that expected the request to be contained in a single message. The revised approach uses the method that is advocated in the unix docs to detect a broken TCP stream which is that if the blocking `read` operation returns 0 bytes then the socket is closed. So this PR creates a buffer to hold the request, attempts to send it and then reads the response. If the response was length 0 it will attempt to get a fresh socket and send the request a second time. ACKs for top commit: apoelstra: ACK 0de1c58 Tree-SHA512: 0871a0c57b3d63b2d7b0ebd4bb1bb2f4f68bb88b7fe55fa8f3566f49fbd3aa33920e7e953e50320797bf2b1791ea223e6ef40f57901fbc3908a005e3ea167f77
I have this strange behaviour with a Discord bot that I'm currently making.
For a cryptocurrency project, I am using rust-jsonrpc as a client to query that cryptocurrency's blockchain. It uses the same RPC mechanism that Bitcoin uses, so I'm using this crate and it has been working fine for quite some time.
Because I have to do many RPCs, I store an instance of a rust-jsonrpc client as global data of the bot. This global data is essentially a
Box::pin(async move { Data } )
where I store the client as a member of Data. (the bot is made using poise, and in thissetup
function is where Data gets initiated)When I start the bot and keep it running for a while (30+ sec) and get the client from global data and do a
getnewaddress
RPC, I am getting a HttpResponseTooShort error:error: JsonRPC(Transport(HttpResponseTooShort { actual: 0, needed: 12 }))
. It happens every time I use this call after at least 30 seconds of idling and I can't figure out why this happens. A second request within 30 seconds works just fine.I've already checked if the problem is keeping a client around for a while:
(I built a wrapper like https://github.com/rust-bitcoin/rust-bitcoincore-rpc for this cryptocurrency project)
This doesn't appear to be a problem. I can't figure out what is, though. My guess would be that I keep a connection open for too long, but I can't figure this out, as it appears to be working in a separate environment.
Any ideas?
The text was updated successfully, but these errors were encountered: