faild with err Post "http://geth:8545": context deadline exceeded #210
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/ipld-eth-server#210
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
or
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?
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).
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.
#223 and #221 should prevent this from the ipld-eth-server side.