OVPL controller timeout for large sized repo

[jayanthsagar]

When OVPL is trying to release a lab of 1+ GB sized repositories the controller throws back "server is taking too long to respond", but OVPL is cloning the repo in background, if there is no network issues, the repo gets cloned and lab gets deployed successfully on a container but the developer doesn't know the details regarding the status of the lab.

[travula]

We should use web sockets to display to enable communication both ways. (server - client)

[ecthiender]

This would not solve the issue right. The issue is when ADS is cloning a
repo and the repo is too large(~>1GB), it will take a lot of time for it to
clone and in the meantime ADS times out and as a consequence, the lab
installation fails.

Even if we have websockets for two way communication (so that the server
can push the logs to the client), it is not going to solve this issue. We
have to handle, in ADS, cloning of large repo, or we have threshold on the
repo size. I think the latter is a better idea. I think it doesn't make
sense to have source code repositories in order of GBs. I'm sure if we
think about it, we can come up with lot many implications of having large
repo sizes.

On Fri, Apr 17, 2015 at 12:08 PM, travula [email protected] wrote:

We should use web sockets to display to enable communication both ways.
(server - client)

—
Reply to this email directly or view it on GitHub
#8 (comment).

[ecthiender]

Thinking about it more, maybe having websocket logs solve this issue, the browser won't wait on a traditional HTTP method to return (in which it usually times out after ~10 mins). There would be a websocket connection which would keep updating the client(browser) about the current happenings.

Hence the user might actually see that clone is taking such amount of time. Having websockets based progress updation might solve this issue.