-
Notifications
You must be signed in to change notification settings - Fork 432
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
[Fix] MultiSyncModeSelector
.Changed
event propagation being blocked by SyncFeed
#6529
[Fix] MultiSyncModeSelector
.Changed
event propagation being blocked by SyncFeed
#6529
Conversation
MultiSyncModeSelector
.changed
event propagation being blocked by other event handlersMultiSyncModeSelector
.Changed
event propagation being blocked by other event handlers
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.
Interesting solution! 😊
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.
Why this is solving the issue? What is the technical cause of the issue? If someone is blocking the Changed
handler, maybe that subscription needs to be parallelized and not the invocation?
if (Changed is not null) | ||
{ | ||
Parallel.ForEach(Changed.GetInvocationList(), | ||
deleg => deleg.DynamicInvoke(this, args)); | ||
} |
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.
I think it should not happen, but in theory pattern is to do a local copy to avoid NullReferenceException
and be thread-safe:
https://stackoverflow.com/questions/33166143/local-copy-of-event
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.
😲 You learn something every day
What was the problem? |
Multiple events subscribed to the event; important one is second, first one takes a while to return and they are executed in order |
@LukaszRozmej not entirely sure which delegate is blocking the invocation. also, parallelizing the the delegate method could lead to its own problems in my opinion (with concurrency and race conditions). Additionally, This solution guarantees that all delegates finish executing before continuing to execute the rest of the code. |
I will not merge this till it is properly tested and be sure it will resolve the issue. @kamilchodola waiting on your confirmation, as i am not sure how exactly you were able to produce it. was not able to do so. |
MultiSyncModeSelector
.Changed
event propagation being blocked by other event handlersMultiSyncModeSelector
.Changed
event propagation being blocked by some subscribers
Well it makes it explicit and something to handle by the end-user, which actually allows for proper handling of race conditions. Now it is hidden. |
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.
Can we make so sync starts only when migrations are done?
I would execute first one parallel explicitly in the handler, don't you think it is better? |
@LukaszRozmej i disagree. since if another syncmode change happens while the handler is still executing the previous one it could lead to a race condition. |
51bb2b7
to
ec355fd
Compare
MultiSyncModeSelector
.Changed
event propagation being blocked by some subscribersMultiSyncModeSelector
.Changed
event propagation being blocked by SyncFeed
@smartprogrammer93 @LukaszRozmej what about this one? |
Ready from my side. Feel free to merge it if no more testing is needed. @kamilchodola |
Fixes #6481
Changes
SyncFeed
'sIntialize
method takes a while. Call to it made async.Types of changes
What types of changes does your code introduce?
Testing
Requires testing
If yes, did you write tests?
Documentation
Requires documentation update
Requires explanation in Release Notes