faild with err Post "http://geth:8545": context deadline exceeded #210

Closed
opened 2022-12-22 20:05:40 +00:00 by telackey · 5 comments
Contributor

While running a tool that executes a single eth_call, eth_blockNumber, eth_getStorageAt at a time after a few minutes of it looping, I observed repeated errors in the logs of the form:

time="2022-12-22T20:01:02Z" level=error msg="writeStateDiffFor 0xd9ee39c319ebb4a2afde56d292397f0dc524aca89d85e100d534b0565121fdb6 faild with err Post \"http://geth:8545\": context deadline exceeded"

or

time="2022-12-22T18:43:52Z" level=error msg="writeStateDiffFor 0xd9ee39c319ebb4a2afde56d292397f0dc524aca89d85e100d534b0565121fdb6 faild with err Post \"http://geth:8545/\": EOF"

I am assuming these are related to forwarded eth_calls, but that is not confirmed.

While running a tool that executes a single eth_call, eth_blockNumber, eth_getStorageAt at a time after a few minutes of it looping, I observed repeated errors in the logs of the form: ``` time="2022-12-22T20:01:02Z" level=error msg="writeStateDiffFor 0xd9ee39c319ebb4a2afde56d292397f0dc524aca89d85e100d534b0565121fdb6 faild with err Post \"http://geth:8545\": context deadline exceeded" ``` or ``` time="2022-12-22T18:43:52Z" level=error msg="writeStateDiffFor 0xd9ee39c319ebb4a2afde56d292397f0dc524aca89d85e100d534b0565121fdb6 faild with err Post \"http://geth:8545/\": EOF" ``` I am assuming these are related to forwarded eth_calls, but that is not confirmed.

Does the error message have anything to do with your requests? It says "writeStateDiffFor" which implies some code to do with state diffing, which is not code to do with your requests. Perhaps this is some general load interference issue? Your requests imposed load, and under load some problem in state diffing arises?

Does the error message have anything to do with your requests? It says "writeStateDiffFor" which implies some code to do with state diffing, which is not code to do with your requests. Perhaps this is some general load interference issue? Your requests imposed load, and under load some problem in state diffing arises?

Also, do we know why ipld-eth-server is doing state diffing? Or is it? Could the error actually be coming from geth?

Also, do we know why ipld-eth-server is doing state diffing? Or is it? Could the error actually be coming from geth?
Author
Contributor

Also, do we know why ipld-eth-server is doing state diffing? Or is it? Could the error actually be coming from geth?

It seems to be triggering/asking for the statediffing to be done by geth, which geth either fails to respond to in a timely manner (causing this error) or responds with an error, such as #209. #209 has additional info. (I strongly suspect they are two manifestations of the same underlying issue).

> Also, do we know why ipld-eth-server is doing state diffing? Or is it? Could the error actually be coming from geth? It seems to be triggering/asking for the statediffing to be done by geth, which geth either fails to respond to in a timely manner (causing this error) or responds with an error, such as #209. #209 has additional info. (I strongly suspect they are two manifestations of the same underlying issue).
Member

Yeah I think they are related. If it is due to https://github.com/cerc-io/ipld-eth-server/issues/209#issuecomment-1368058574 and the geth node being overloaded with more statediffing requests than it can handle, then as it tries to process more requests concurrently it takes longer for any single one to be finished and they begin to either timeout or hit errors due to the connection pool being overloaded.

Default timeout of 10s is being used https://github.com/cerc-io/go-ethereum/blob/v1.10.25-statediff-v4/rpc/client.go#L43 which is already cutting it close to how long a high-complexity statediff could take to generate in isolation on "decent" hardware.

Yeah I think they are related. If it is due to https://github.com/cerc-io/ipld-eth-server/issues/209#issuecomment-1368058574 and the geth node being overloaded with more statediffing requests than it can handle, then as it tries to process more requests concurrently it takes longer for any single one to be finished and they begin to either timeout or hit errors due to the connection pool being overloaded. Default timeout of 10s is being used https://github.com/cerc-io/go-ethereum/blob/v1.10.25-statediff-v4/rpc/client.go#L43 which is already cutting it close to how long a high-complexity statediff could take to generate in isolation on "decent" hardware.
Author
Contributor

#223 and #221 should prevent this from the ipld-eth-server side.

#223 and #221 should prevent this from the ipld-eth-server side.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/ipld-eth-server#210
No description provided.