-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to increase timeout duration? #76
Comments
I'm facing the same issue guys. Token Market team, can you give us a hint or something? |
@namanyayg check this out: def tweak_chain(project, deployment_name):
with project.get_chain(deployment_name) as chain:
chain.wait.timeout = 9999
# in deploy contracts.py -> def main(deployment_file, deployment_name, address):
project = Project()
tweak_chain(project, deployment_name) # <-- here we go! |
@AlexanderC Thanks! Looks like this would work -- I managed to deploy all my contracts soon after Byzantium when my timeouts stopped coming (due to faster mining times perhaps?) Would appreciate an official update from TokenMarketNet team, but I think we can close this. |
i get these timeouts all the time.. do i really need to patch the code in this way as a workaround? |
The problem is that the current Populus version does not support setting timeout when deploying linked contracts (contracts having libraries in them that need to be deployed). So far we have fixed this by just hardcoding a different timeout in Populus. Last time I checked @petri and @voith might have a patch coming in. |
Yes, I'll be working on this today! |
I have opened ethereum/populus#464 to fix this issue. |
@AlexanderC mate this proposed solution does not solve the issue either, what else can be tried in the interim or is a solution released for it ? thanks also note this will only even execute if the deployment_name is same as the chain name
|
in the interim the workaround was to change the timeout values in the following files |
Hi, often facing this error in various steps of my deployment script:
What is the reason for this error? I'm running my client in a VirtualBox so my options regarding hardware are slightly limited. Is there some way to perhaps increase the timeout duration?
For reference, I'm running parity using the command
parity --unlock="0x0foo" --password="y" --mode active --tracing off --pruning fast --db-compaction ssd --cache-size 4096 --force-ui ui
and this is whathtop
reads like during normal syncing of the mainnet chain.The text was updated successfully, but these errors were encountered: