CODEWITHSUNDEEP
iisblazorblazor-server-side
Jason D
Jason D

Reputation: 2087

How to keep Blazor Server connection active when IIS is recycling the application pool

I am building a Blazor Server intranet application for my customer. One of the requirements is that they can stay logged in indefinitely. If they starting inputting some data on a Friday afternoon, they should be able to return on Monday morning and continue working without interruption.

I came to observe that the client-side was getting disconnected from the server about once per day. When this happened I would see the dreaded Blazor error “Reconnection failed. Try reloading the page if you’re unable to reconnect.”. If I click the link to Reload, it immediately reconnects to my server, but any work in process would be lost.

I found the root cause: by default, IIS is recycling the application pool every 29 hours. When this happens, the Blazor SignalR connection is getting interrupted, and hence the code running in the browser times out and disconnects.

I am able to work around this issue by disabling application pool recycling altogether. So far, it looks like that works fine (I could keep connectivity for the past 3 days). But I am worried this may not be safe long term, since application pool recycling helps deal with issues such as memory leaks, fragmentation, etc.

SO, my question is: is it possible to configure IIS in way that I can recycle the application pool AND also keep my blazor server connection available during that recycle period?

Upvotes: 2

Views: 2449

Answers (1)

Ding Peng
Ding Peng

Reputation: 3974

When you recycle an application pool, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycle, HTTP.SYS transparently routes the new requests to the new worker process. Thus, the client never "loses all connectivity" to the server - the TCP connection is never lost - and never notices the process recycle.

I believe your problem is with the applications running in your application pool that store state within the process, such as whether a user is logged in or not. Everytime the process recycles, that state is automatically lost... which is by-design since that is what a process recycle accomplishes. As a result, your users "lose all connectivity" and "have to log back into their applications" to re-establish that lost state. The only way to fix this is for your applications to store its state outside of the IIS worker process such that it is friendly to being recycled.

The following blog entry talks more about what is going on:

https://learn.microsoft.com/en-us/archive/blogs/david.wang/why-do-i-lose-asp-session-state-on-iis6

Upvotes: 0

Related Questions