@Hooverdan96 I know what we are putting in here has much reduced timeouts to what we had: but I'm pretty sure, with the very different nature of gthread workers in comparison to our prior inappropriate use of sync workers, we are moving in the right direction. So I'd like to return these timeouts to their default of 30 seconds to re-assess what we actually need here. Plus the prior sync worker type was not sensitive to on-going activity; where-as gthread workers are, so they will not be timed out if they are still dealing with an ongoing/active communication.

Note also, with the custom log additions here, we should now have far better timing info with which to debug such things as our available rock-on update mechanism. I intend also to use this new log entry to see if server side compression can help us out on that one.

I have also now removed the distracting gunicorn file that should have been deleted long ago. My apologies for leaving that in place all this time.

@FroggyFlox I'll pop this one in also to enable your ongoing development to be re-based prior to submission.

@phillxnet I think that's good to return the lower numbers. With the changes you mentioned I would hope that it becomes less of a potential bottleneck, and once @FroggyFlox is able to take another look at how we do the refresh/downloads, there might be possibly a more effective way of doing delta updates ...

Testing

An RPM was successfully built and installed with this match pre-merged. The resulting instance was able to:

• Initiate via the Web-UI setup.
• Import a pool.
• Configure Rock-ons system.
• Install and run the netdata Rock-on.
• Peform a re-raid (balance).
• Perform a scrub.

So we look to have persisted a working thread arrangement having moved to the very different gthread - at least for the main app. And we now have a Py3 only gunicorn.