* Added feature phases
* BasicsPhase and DatabasePhase to the required files. Server now has Feature circles and does not boot. Will be sorted out later on.
* Added ClusterPhase to features
* Added V8Phase to the required features
* Added AQLPhase to the affected features
* Added ServerPhase to Features
* Added FoxxPhase to the relevant features
* Added AgencyPhase to the relevant features
* Moved registration from local variable SYS_SYSTEM_REPLICATION_FACTOR from cluster to V8 as their ordering is now vice versa
* Moved Bootstrap feature into FoxxPhase. It could be moved to ServerPhase easily if the FoxxQueue dependency would be removed
* Final movement of Startup Phases. Now solved all circles.
* Removed merge conflict
* Moved ReplicationTimeout into cluster phase and fixed cross-phase requirements
* Added greetings phase. This phase separates the Basics Phase and is the first to be run. Includes Logger and Hello/Goodbye
* Added the GreetingsPhase in the corresponding features. Now all BasicsPhase features start after greetings Phase. There is some issue in this branch which prevents the Agency from Gossipping right now. Will be fixed next
* Moved creation of the Agent into the prepare phase of the feature. THereby it is guaranteed that agents at least exists before the GeneralServer is activating endpoints
* Recovery needs to be started after the ServerID
* Moved log output of FeaturePhases to DEBUG instead of ERROR.
* Added feature phases for clients
* ClusterFeature now does not directly require AgencyFeature any more
* Added requirement of TravEngineRegistryFeature in AQL feature. Otherwise shutdown may be undefined
* The ApplicationServer can now handout the list of ordered features. Used for testing purposes
* Fixed IResearchVew Tests Setup to honor new feature ordering
* Fixed IResearchViewDBServer Tests Setup to honor new feature ordering
* Started fixing IResearchView Coordinator tests with startup ordering. Not finished yet
* Added startup phases to ViewCoordinator test
* Disabled expected logoutput in ClusterRepairsTest
* Fixed indention in test code
* LinkCoordinator now honors startup ordering
* Link meta now honors startup rdering
* Supress expected cluster logs in ViewTest
* Removed '#' accidentially added.
* make arangorestore not report errors about the target database not found
when it is invoked with option `--create-database true`. In this case,
arangorestore should not print an error but simply create the target
database. This patch implements this change.
Additionally, it aborts the startup of arangorestore in case there are
any errors. Previously, the startup phase went on even when no connection
could be established, which led to useless follow-up errors being printed.
* simplify error handling a bit
* do not use V8 variant of AQL functions in early optimization stage when a C++ variant is available
* additionally, simplify AQL function definitions and aliases
* warn when more than 90% of max mappings are in use
* added C++ variant of replication catchup
* added `--log.role` option
* updated CHANGELOG
* removed non-existing scheduler.threads option from config
* removed useless __FILE__, __LINE__ invocations
* updated CHANGELOG
* allow a priority V8 context
* remove TRI_CORE_MEM_ZONE
* try to fix Windows errors & warnings
* cleanup
* removed memory zones altogether
* exclude system collections from collection tests
this changes the server startup option `--database.check-30-revisions` from a boolean (true/false)
parameter to a string parameter with the following possible values:
- "fail":
will validate _rev values of 3.0 collections on collection loading and throw an exception when invalid _rev values are found.
in this case collections with invalid _rev values are marked as corrupted and cannot be used in the ArangoDB 3.1 instance.
the fix procedure for such collections is to export the collections from 3.0 database with arangodump and restore them in 3.1 with arangorestore.
collections that do not contain invalid _rev values are marked as ok and will not be re-checked on following loads.
collections that contain invalid _rev values will be re-checked on following loads.
- "true":
will validate _rev values of 3.0 collections on collection loading and print a warning when invalid _rev values are found.
in this case collections with invalid _rev values can be used in the ArangoDB 3.1 instance.
however, subsequent operations on documents with invalid _rev values may silently fail or fail with explicit errors.
the fix procedure for such collections is to export the collections from 3.0 database with arangodump and restore them in 3.1 with arangorestore.
collections that do not contain invalid _rev values are marked as ok and will not be re-checked on following loads.
collections that contain invalid _rev values will be re-checked on following loads.
- "false":
will not validate _rev values on collection loading and not print warnings.
no hint is given when invalid _rev values are found.
subsequent operations on documents with invalid _rev values may silently fail or fail with explicit errors.
this setting does not affect whether collections are re-checked later.
collections will be re-checked on following loads if `--database.check-30-revisions` is later set to either `true` or `fail`.
The change also suppresses warnings that were printed when collections were restored using arangorestore, and the restore
data contained invalid _rev values. Now these warnings are suppressed, and new HLC _rev values are generated for these documents
as before.
This adds an option --default-replication-factor to arangorestore and
makes it more convenient to specify the number of shards for restored
collections.
Jan
Lars Maier
Vasiliy
sleto-it
Simon
Wilfried Goesgens
Michael Hackstein
jsteemann
Dan Larkin-York
Frank Celler
Kaveh Vahedipour
Jan Christoph Uhde
Max Neunhoeffer