* Add missing dependencies to IResearchAnalyzerFeature
* First all features beginShutdown, then stop.
This is for the case of immediate shutdown if the startup did not work.
* Consolidated _servers and _serverAdvertisedEndpoints, added rebootId, prepared change notifications
* Cleanup
* Added a RebootId type
* Began implementing RebootTracker (still WIP)
* Moved RebootId operators into the class
* Removed RebootId operator<< again
* Added tests, added CallbackGuard, removed/commented old RebootTracker code
* Fix: do not try to call unset callbacks
* Split one test, added another
* Added more tests
* Renamed tests, added more tests
* Fixed missing variable declarations
* Let MockServer appear to be started
* Reorded test, fixed naming
* Implemented callMeOnChange()
* Re-implemented RebootTracker (not yet working)
* Resolved a TODO, updated a test, added comments
* Call old callbacks immediately
* Fixed tests
* Use EXPECT_* instead of ASSERT_*
* Suppress a log message
* Resolved TODOs
* Reverted changes on reading ServersRegistered
* Update RebootTracker
* Introduce `rebootId` into ServerState for Cluster
* A server *boots* if it is started on a previously non-existing data
directory and hence does not have a UUID yet.
* A server *reboots* if it is started on a pre-existing data directory
We keep the rebootId in the cluster's agency under
Current/ServersKnown/$uuid/rebootId.
When rebooting (and subsequently re-joining a cluster), the server increments
its rebootId in Phase 2 of registration. This way it can be detected within the
cluster whether a server was restarted.
This information will later be used to handle cases where server restarts can
lead to problems, for example with transactions or in-progress queries.
* Move rebootId into Current/ServersKnown/
* Fixed typo
* Fixed log ids
* Add deletion of ServersKnown/UUID from agency
* Add deletion of Current/ServersKnown/UUID to removeServer
* Clean up readRebootIdFromAgency and add retry loop around it
* Bugfix
* Added nolint comments
* Fixed initialization order
* Fixed ClusterInfo-test
* Added log messages
* Revert "Fixed ClusterInfo-test"
This reverts commit d983596979.
* Disabled assertion for google tests
* Ignore windows compile warning
* Always call loadServers in loadCurrent
* Fix really subtle bug when not returning a value
* Introduce `rebootId` into ServerState for Cluster
* A server *boots* if it is started on a previously non-existing data
directory and hence does not have a UUID yet.
* A server *reboots* if it is started on a pre-existing data directory
We keep the rebootId in the cluster's agency under
Current/ServersKnown/$uuid/rebootId.
When rebooting (and subsequently re-joining a cluster), the server increments
its rebootId in Phase 2 of registration. This way it can be detected within the
cluster whether a server was restarted.
This information will later be used to handle cases where server restarts can
lead to problems, for example with transactions or in-progress queries.
* Move rebootId into Current/ServersKnown/
* Add deletion of ServersKnown/UUID from agency
* Add deletion of Current/ServersKnown/UUID to removeServer
* Clean up readRebootIdFromAgency and add retry loop around it
* Fixed compile error due to forbidden implicit cast
* Fixed compile error on windows
* Fixed compile error due to devel merge
* Removed dead comment
* Removed TODO note
* Extended comment
* Removed TODO note
* Fixed using an invalidated iterator
* Copy string only if necessary
* Fixed compile error
* Added startup error for bad temporary directory setting.
If the temporary directory (--temp.path) setting is identical to the database
directory (`--database.directory`) this can eventually lead to data loss, as
temporary files may be created inside the temporary directory, causing overwrites of
existing database files/directories with the same names.
Additionally the temporary directory may be cleaned at some point, and this would lead
to an unintended cleanup of the database files/directories as well.
Now, if the database directory and temporary directory are set to the same path, there
will be a startup warning about potential data loss (though in ArangoDB 3.4 allowing to
continue the startup - in 3.5 and higher we will abort the startup).
* make rspec timeouteable (on windows for now)
* add timeout state, fix windows implementation
* abort testrun if a timeout in rspec occured
* lint
* fix scope of procdump stopper
* fix include scope
* fix invokation
* use proper variable to wait for