Conversation
BrennanConroy
left a comment
There was a problem hiding this comment.
Looks good, but lets wait for some customer feedback, or until we can test it ourselves.
If there is no keep alive configured, we cannot assume that timer callbacks will run frequently enough to keep lastActiveAt updated. #4536
|
I'm going to merge this so people can try out I ran the build locally and it passed. If there are any issues I'll submit a follow up PR. |
|
Great work and really hope this fixes Chrome reconnecting SignalR over and over. Is there a preview for AspNetCore 3.1? |
|
ASP.NET Core 3.1 has been out for over a year. Also, this repo is for ASP.NET SignalR which is unrelated to ASP.NET Core. If you're looking to try out the recent changes to the ASP.NET SignalR JavaScript client, you can use
|
|
Hi Brennan, Sorry I confused this repo for aspnet/SignalR (EDIT: dotnet/aspnetcore), as #4536 describes an identical issue that we're seeing in the AspNetCore version of SignalR. Didn't mean to offend. Cheers. |
|
@nitzzzu I see you've deleted the following comment
Does this mean 2.4.2-preview2 is working for you? |
|
@halter73 yes. I've just used the jquery. signalr.js on client side while keeping an older version on the server side and it seems to work fine |
| // run frequently enough to keep lastActiveAt updated. | ||
| // https://github.com/SignalR/SignalR/issues/4536 | ||
| if (!connection._.keepAliveData.activated || | ||
| new Date().getTime() - connection._.lastActiveAt < connection.reconnectWindow) { |
There was a problem hiding this comment.
What about using a "forward only" time like performance.now() which does not depend on the system clock which might change with timezones / NTP / manually?
|
Hi from where can i install 2.4.2 version with this fix? i cant see the npm library updated. Apology for my lack of insight here |
Hi @MukeshJ2506, what worked for me was this:
I don't usually work with NuGet packages, so perhaps there are much easier ways ;-) |
@wbeeftink Appreciate your response. thank you 😃 |
I'm hoping this fixes #4536.
markLastMessageshould still run frequently enough to keeplastMessageAtup-to-date despite chrome's new timer throttling becausemarkLastMessagecalled by "network response handlers". This means we have to effectively disable ourlastMessageAtchecking logic if keep-alives are disabled.