I just had an unusual long startup of arangod where it was stuck for over 3 minutes. Based on the log, I suspect it was stuck in checkAvailableVersions perhaps because my connection to arangodb.com was slow.
...
2016-10-07T05:24:10Z [1651] INFO In database '_system': Database is up-to-date (20811/prod/standalone/existing)
2016-10-07T05:27:23Z [1651] INFO Please note that a new major version '3.0.10' is available
2016-10-07T05:27:23Z [1651] INFO file-descriptors (nofiles) hard limit is -1, soft limit is 10240
2016-10-07T05:27:23Z [1651] INFO Authentication is turned off
2016-10-07T05:27:23Z [1651] INFO ArangoDB (version 2.8.11 [darwin]) is ready for business. Have fun!
This is concerning me because I need to minimize downtime in production and an unresponsive or slow arangodb.com/repositories/versions.php should not increase my downtime.
It seems that the timeout parameter in https://github.com/arangodb/arangodb/blob/2d4e5ababc6ece71a2453b4ca6a1dae5e774a0cb/js/common/modules/%40arangodb/common.js#L487 doesn't work because if I change the URL to "http://deelay.me/5000/https://www.arangodb.com/repositories/versions.php?version=" and the timeout value to 2, it's still waiting.
Edit: I was confused about the timeout value because I assumed it's in milliseconds instead of seconds. The timeout works fine, it's just obscenely large in 2.8. If you have another bugfix release for 2.8 in the pipeline, I'd appreciate you changing the timeout value from 300 to 2 seconds.
Ideally, checkAvailableVersions would be changed such that it does not delay startup of arangod at all because in some production environments, every second counts.
I have pushed a change that decreases the connect timeout from 300 to 5 seconds in the 2.8 and 3.0 branches, and from 10 to 5 seconds in devel.
That should make the problem much less severe, but the process will still be blocking on the connect at startup. Changing this to an async non-blocking request is a bit more work, so I will be re-labeling this issue as a feature request now.
The most pragmatic solution would probably be to just remove this code. Between Aardvark, Twitter, your blog, homebrew, and GitHub all telling me about newly available versions, I don't think arangod informing me of new versions when starting up is adding that much value.
Or only do it based on the absence of some env var or parameter.
Or upload a static text file that includes the latest version number to S3, fronted with CloudFront, and download that instead of accessing your own PHP server.
My vote is to just remove it :)
Or an option to explicitly opt in in version checking. --server.check-version
I actually don't like the idea, that ArangoDB is telephoning back home every time its startet.
ArangoDB Enterprise doesn't look for upstream newer versions.
Most helpful comment
Or an option to explicitly opt in in version checking.
--server.check-versionI actually don't like the idea, that ArangoDB is telephoning back home every time its startet.