-
Notifications
You must be signed in to change notification settings - Fork 222
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
Wait for TFTP downloads #886
base: develop
Are you sure you want to change the base?
Conversation
The /fetch_boot_file API is used to download TFTP files. The HttpDownload task is implemented as a thread. Previously it was fired off and there was no way to see the result. This implements code that waits for some time before telling the client the task is still running. There is no way for the client to find out if it really did finish.
Related: #472 implemented a mechanism to poll the status. Probably worth looking at that downloader implementation even if we continue to wrap curl. |
# This waits for a bit before telling the client we've accepted it | ||
# TODO: implement a mechanism to poll for completion | ||
if result.respond_to(:join) | ||
202 unless result.join(5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming webrick is single threaded, does this mean that this will block for up to five seconds, preventing any other requests from being processed during that time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly a concern. I was debating this, how to make it configurable. But I also assumed we at least had some threads in Webrick. Yet I can't find proof for it. That may invalidate the whole approach.
Perhaps a mechanism similar to #472 to return a HTTP 202 with a task ID to poll for is a better approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For an unrelated item I looked into this. Webrick has a single thread to accept clients, but then starts a thread for every client.
So that would mean this just runs a sleep in its own thread, I don't see how it would be a problem.
Still, a proper task ID that can be monitored is a much better API. Both approaches aren't mutually exclusive though.
The /fetch_boot_file API is used to download TFTP files. The HttpDownload task is implemented as a thread. Previously it was fired off and there was no way to see the result. This implements code that waits for some time before telling the client the task is still running. There is no way for the client to find out if it really did finish.
Currently untested, but this at least shows the principle.