This repository has been archived by the owner on Feb 15, 2018. It is now read-only.
Add startup lock support (general framework + tested etcd implementation) #98
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This required completely reworking startup sequence in `autocluster.erl` without making the existing dozen step sequence into an incomprehensible mess. Now steps are more independent and are executed in order with function that provides something like State + Either monads. Boot process is now split into 3 stages: - First stage roughly corresponds to original implementation - Second step is responsible for registering node in the backend. Also TTL timers are now started there, instead of spreading `-rabbit_boot_steps` through backend modules. This makes `autocluster.erl` the single source of truth about what is actually happening during startup. - Third stage is responsible for releasing startup lock. We need it because of `ignore` failure mode - we want the lock to be released even if some prior steps failed. During this rework it became evident that explicit mnesia:reset/0 is not needed (more thorough explanation is in comments for `autocluster:maybe_cluster/1`). Startup locking support should work the same way for every backend, but for now the only working implementation is for `etcd`. It even has some property-based tests =) Other backend fall back to original random delay behaviour. Also it looks like `dialyzer` ignores type specs in comments - because some of types there were definitely wrong, and converting to them to `-spec` caused a lot of barfing from `dialyzer`.
binarin
force-pushed
the
startup-locking-support
branch
from
039a92b
to
1a8b010
Compare
Current coverage is 53.84% (diff: 62.50%)@@ master #98 diff @@
==========================================
Files 13 14 +1
Lines 513 611 +98
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 214 329 +115
+ Misses 299 282 -17
Partials 0 0
|
|
@gmr Will you have some time to look into this PR in the nearest future? |
|
Yes, will do... |
|
@gmr we'd like to get this feature into 3.7.0. May I merge it here first? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm sorry for such a big patch, but I think there was no other way. (Also this PR includes patch from #96, which makes diff even bigger).
This required completely reworking startup sequence in
autocluster.erl- as adding lockingwould have made the existing dozen step sequence into an incomprehensible
mess. Now steps are more independent and are executed in order with
function that provides something like State + Either monads.
Boot process is now split into 3 stages:
TTL timers are now started there, instead of spreading
-rabbit_boot_stepsthrough backend modules. This makesautocluster.erlthe single source of truth about what is actuallyhappening during startup.
because of
ignorefailure mode - we want the lock to be releasedeven if some prior steps failed.
During this rework it became evident that explicit mnesia:reset/0 is not
needed (more thorough explanation is in comments for
autocluster:maybe_cluster/1).Startup locking support should work the same way for every backend, but
for now the only working implementation is for
etcd. It even has someproperty-based tests =)
Other backend fall back to original random delay behaviour.
Also it looks like
dialyzerignores type specs in comments - becausesome of types there were definitely wrong, and converting to them to
-speccaused a lot of barfing fromdialyzer.