-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSI protocol for multi-clusters #1800
GSI protocol for multi-clusters #1800
Conversation
@sebastianburckhardt great work! Question... Since every silo has a Besides that question, greet work. LGTM. Thanks! #Closed |
I know it does not look that way, but there is actually only one grain directory. I agree that it is definitely cleaner that way (consider handoff etc.). |
Ok got it. Thanks! Great work, LGTM #Closed |
Optimized multiple Linq Count calls with Aggregate
} | ||
|
||
var precLeft = grain.GetUniformHashCode() ^ clusterLeft.GetHashCode(); | ||
var precRight = grain.GetUniformHashCode() ^ clusterRight.GetHashCode(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should not use String.GetHashCode()
. Create and use a uniform hashcode instead, as the value of GetHashCode might be different depending on where it is ran. #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok. #Closed
Unregistration of global-single-instance grains seems to not have not been thought through completely. Need to fix this. I think we can do the equivalent of what is done within a cluster (send unregistration messages, and if those should get lost for any reason, fall back on removing stale directory entries when detecting NonExistentActivation exceptions). #Closed |
I think that's alright. I can't think of a simple better solution. Let's see how it works, iterate if necessary. #Closed |
@@ -124,6 +126,22 @@ public bool RemoveActivation(ActivationId act, bool force) | |||
return Instances.Count == 0; | |||
} | |||
|
|||
public IActivationInfo LookupAndRemoveActivation(ActivationAddress address, bool force) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this method shares some (non-trivial) logic duplication with the method above (RemoveActivation
) although they differ slightly in the case of force==true. Is this by design or should they be doing the same and avoiding duplication instead? #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the case I implemented, I need to know if an activation was removed, and if so, what was its content.
I could not see how to do that without adding a new LookupAndRemove
function on the directory.
The existing RemoveActivation
does not always do a lookup, and does not return an activation. Instead, it returns a boolean indicating whether there are any activations left after the remove.
#Closed
Refactor GSI response tracker
Looks like we are down to a single remaining design issue - with Cluster ID on the client. I'll try to look if there's a reasonable way to avoid passing it through client config. #Closed |
I submitted a PR - sebastianburckhardt#6 against @sebastianburckhardt's branch to eliminate the need to configure cluster ID on the client side. |
Change initialization of OutsideRuntimeClient to start with a handshake client ID, and update it with cluster ID received from gateway.
…kCycle field can cause NullPointerException).
Shouldn't 84ee457 go as a separate PR, if it fixes a general bug? |
If you prefer. It's your call. (It's a very small change). |
I think it is better to review (and merge if everything is fine) separately. You can leave it in this branch for now for testing. When you finally rebase/squash, it will disappear if it's already merge to master by then. |
…onflicts in src/Orleans/Messaging/Message.cs caused by dotnet#2124
…BatchWorker.cs due to dotnet#2133
I got a dozen functional test failures. Need to investigate what's going on there. |
Thanks a lot @sebastianburckhardt and everyone involved in this effort. It took 3 months, but this is IN! |
It was an epic effort. Thank you all! |
Implements Global-single-instance registration strategy. This is the next installment of the Geo-Distribution Project #948.