Aspnetcore: Dispose doesnt work when page is refreshed (server-side blazor)

Created on 7 Nov 2018  路  11Comments  路  Source: dotnet/aspnetcore

Hello I was trying to make the fetchdata example update values without refreshing page or clicking buttons. And I found out that I can use timer which seemed like working ok. But after testing with different data it was acting strange and I found out that page doesnt dispose the timer when I go to different page and its not displayed anymore.
That was solved by adding dispose but it didnt solve different issue.. When I press F5 while on /fetchdata page it reloads and doesnt dispose the timer. And then it runs twice. I tried it by adding int into ForecastService and it increment everytime GetForecastAsync is called. After 10 refreshes it increment +10 every second instead of +1.
I hope it makes sense.

@functions {
WeatherForecast[] forecasts;
Timer timer;
private async void Update()
{
    forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
    StateHasChanged();
}

protected override async Task OnInitAsync()
{
    timer = new Timer(1000);
    timer.Elapsed += (sender, args) => Update();
    timer.Start();
    Update();
}

public void Dispose()
{
    timer.Dispose();
}
}
Done area-blazor bug

Most helpful comment

Yes, this is one of several areas of cleanup and resource-usage resilience we know we need to implement in the server-side model. Thanks for raising this - I'll leave it open until we can get to it (which hopefully will be soon).

All 11 comments

It seems a bug indeed from what I can tell it seems it couldn't update the server from SignalR that a page refresh happened to properly dispose the component. You can confirm this on Debug mode wherein creating a breakpoint on the Dispose method gets hit when navigating to other routes while doing a refresh doesn't.

It would probably work if you could manually dispose the component before a refresh triggers via windows.beforeunload event using JSInterop though a more integrated approach from the framework itself to would be ideal. Probably by informing the server a refresh happened.

Edit: I can replicate the counter issue it seems to be incrementing more than 1 per timer tick, it really does seem that the other components isn't disposed and still updating the singleton.

It also appears that Dispose is not called when the browser is closed.

Yes, this is one of several areas of cleanup and resource-usage resilience we know we need to implement in the server-side model. Thanks for raising this - I'll leave it open until we can get to it (which hopefully will be soon).

I could replicate this too... Also server-side.
After hours of trying to find a bug in my event handlers I found that I was subscribing to events from blazor components but never unsuscribing due to the Dispose not being called ever... glad to found here that it was just a bug =)

Clearing milestone, backlog doesn't seem right for this.

@SteveSandersonMS Should we just attach ourselves to beforeunload to dispose the connection / orderly tear down the circuit?

I thought we had resolved this already. I think @pranavkm implemented it.

But if this is still reproducible, we need to be sure that Dispose to be called in all cases, not only when the beforeunload event runs (it wouldn鈥檛 if the user just closed their browser).

@SteveSandersonMS Yeah, the circuit gets set to disconnected when the connection is lost and eventually gets disposed. We can probably close this then. Should we try and be more proactive when we can?

Closing it as it is already done. Keep in mind that dispose will fire up only after the circuit gets reclaimed and not immediately after refresh.

I agree we should consider evicting immediately if we get notification from the client that they are unloading the document. Could we have a backlog item for that?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

UweKeim picture UweKeim  路  3Comments

Kevenvz picture Kevenvz  路  3Comments

TanvirArjel picture TanvirArjel  路  3Comments

githubgitgit picture githubgitgit  路  3Comments

markrendle picture markrendle  路  3Comments