Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Possible Solution idea to ChangeToken.OnChange firing several times. #43129

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

Closed
GCascaes opened this issue Mar 17, 2020 · 5 comments
Closed

Possible Solution idea to ChangeToken.OnChange firing several times. #43129

GCascaes opened this issue Mar 17, 2020 · 5 comments
Labels
area-Extensions-Primitives backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions no-recent-activity

Comments

@GCascaes
Copy link

Is your feature request related to a problem? Please describe.

Yes, it is related to the problem already described in dotnet/aspnetcore#2542, which is the fact that ChangeToken.OnChange fires more than once for a single change.
I would post this idea in that issue, but it is closed, so I had to open this new one.

Describe the solution you'd like

My solution idea, which I used in my project and worked for me, is to, instead of trying to consider only the last OnChange call, to consider only the very first call, and ignore subsequent calls by adding a "cool down period".

I am not sure if this solution is good for all cases, since I was not able to find out if the changes are guaranteed to be complete on the first call, but if that is the case, then this would solve the problem without introducing a delay on the OnChange execution.
Also, not sure if this solution would "solve this without regressing other scenarios", as was mentioned in dotnet/aspnetcore#2542 as the reason for not implementing it in the framework.

I could use some help in answering those questions :)

And, if the answers are that the change is guaranteed to be complete on the first call, and such a solution would not regress other scenarios, here is the way I implemented it in my code, and tested in aspnetcore 3.1:

public class myService{

  private readonly Timer debounceTimer;
  private readonly SemaphoreSlim debounceSemaphore;

  public myService()
  {
    debounceSemaphore = new SemaphoreSlim(1);
    debounceTimer = new Timer( _ => debounceSemaphore.Release());
  }

  private void myOnChangeMethod()
  {
    if (!debounceSemaphore.Wait(0))
      return;
    debounceTimer.Change(1000, Timeout.Infinite);

    // Do actual stuff
  }
}

This way, the first time the method is called, it will be able to acquire the semaphore and will run normally. Also, it will start the timer to release the semaphore only after the coolDownPeriod has passed.
Since all calls happen almost at the same time, the following calls will return for not being able to acquire the semaphore immediately.

Please let me know if the solution is not clear enough, or if I missed some important detail.

Edit: If the answer to the questions is that the solution would be good enough, I can make a generalized version of it and submit a PR. Let me know if this is the case, please.

@ghost
Copy link

ghost commented Oct 1, 2020

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

@JunTaoLuo
Copy link
Contributor

JunTaoLuo commented Oct 1, 2020

It seems to me that debouncing OnChange callback firings is best left up to the user since any change could be "breaking" for other users. The determination on what kind of behaviour best suits the use case should not be made by the framework.

@davidfowl davidfowl transferred this issue from dotnet/aspnetcore Oct 7, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.Threading untriaged New issue has not been triaged by the area owner labels Oct 7, 2020
@ghost
Copy link

ghost commented Oct 7, 2020

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

@eerhardt eerhardt removed the untriaged New issue has not been triaged by the area owner label Oct 7, 2020
@eerhardt eerhardt added this to the Future milestone Oct 7, 2020
@eerhardt eerhardt added the enhancement Product code improvement that does NOT require public API changes/additions label Oct 7, 2020
Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Apr 8, 2025
Copy link
Contributor

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

@dotnet-policy-service dotnet-policy-service bot removed this from the Future milestone Apr 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Extensions-Primitives backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions no-recent-activity
Projects
None yet
Development

No branches or pull requests

5 participants