Skip to content
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

ipfs-cluster-ctl times out very quickly on longer operations #323

Closed
hsanjuan opened this issue Feb 22, 2018 · 1 comment
Closed

ipfs-cluster-ctl times out very quickly on longer operations #323

hsanjuan opened this issue Feb 22, 2018 · 1 comment
Assignees
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@hsanjuan
Copy link
Collaborator

Post http://127.0.0.1:9094/pins/recover?local=true: net/http: request canceled (Client.Timeout ele awaiting headers)

My guess is that the Client is configure with some default timeouts.

  • It should be configurable (as part of the rest/client config)
  • There should be a flag to generally set timeouts in ipfs-cluster-ctl
  • Default should be way higher than right now
@hsanjuan hsanjuan added kind/bug A bug in existing code (including security flaws) help wanted Seeking public contribution on this issue exp/novice Someone with a little familiarity can pick up status/ready Ready to be worked P1 High: Likely tackled by core team if no one steps up labels Feb 22, 2018
@lanzafame lanzafame self-assigned this Mar 9, 2018
@ghost ghost added the status/in-progress In progress label Mar 9, 2018
@lanzafame
Copy link
Contributor

lanzafame commented Mar 9, 2018

@hsanjuan I have had a look into this, and points 1 and 2 are already the case, the rest/client has a timeout configuration and ipfs-cluster-ctl has the --timeout/-t flag for setting that timeout variable. I have raised the timeout default value to 120 seconds, #334 , though am not sure what the ideal would be in this scenario.

@ghost ghost removed the status/in-progress In progress label Mar 13, 2018
@hsanjuan hsanjuan mentioned this issue Mar 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

2 participants