-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Reconnect client after server restart #24
Comments
What exactly doesn't work? Are you persisting messages to a database or keeping everything in memory? |
I have a file system watcher running on app start. This broadcasts file change messages to connected clients. The clients automatically reload stylesheets that have changed. (makes for very fast CSS prototyping) However, if I edit web.config or rebuild the app, the clients stop getting subsequent CSS file change messages. |
So here's the problem, you're using in memory storage for messages so when the app restarts the client is still going, but it's going to be asking for messages with some id > 0. At this point the in memory message store has 0 messages so it can't reply with anything meaningful. You'd need use a persistent IMessageStore or reset the client's message id to 0 when the app domain restarts. |
Try this out https://gist.github.com/1207068 |
I'll add this feature to our default message, in memory message store. |
Thanks for the gist. I've tried it out, but watching the traffic in fiddler shows the client going into an infinite request loop. Each time the connection completes it starts another one. The same message is getting sent repeatedly. Would it be easier for me to send you the project as an example? |
I think it may be a threading issue. I added some heavy locking: https://gist.github.com/1208346 and now it behaves better. The FileSystemWatcher triggers multiple change events and so the GetAllSince code was running multiple times, concurrently, which is probably what causes the weirdness. --- EDIT |
Another approach: offset the message IDs sent to the client (gist updated https://gist.github.com/1208346 ) |
I'm not sure the code is accurate as it's just locking defensively (if it works for you that's fine), but I have to look what kinda of issues you get. If you could send me a link to the project it'd be great. |
Fixed in 29e5768 |
Perfect, thanks David. I'll get my CSS auto-reloading utility up on nuget soon, once the SignalR package is updated. |
It's online! Install-Package ExpressCss |
There seems to be a regression of this issue in the current version. |
If you have a repro can you provide clearer steps and possibly a sample project? Also specify what environment you're running under? (i.e OS, webserver ) |
Sample project: http://dl.dropbox.com/u/21102229/SignalR.Sample.zip I'm using self host on Windows 7 x64 Professional, but I think this should be independent of the hosting environment (everything that uses the in-process message bus). Repro steps:
I guess the regression happened after InProcessMessageStore.cs was refactored into InProcessMessageBus.cs Let me know if you need additional details ;-) |
Ok, I think I've found the issue. I have implemented this check already and it fixes the issue in my tests. Will provide a pull request later on so you can have a look at it ;-) |
I can repro this now with your sample app. I'll look at the previous fix and make sure we have tests that verify this behavior. |
There is a small glitch with the trace information output. In 1d6ce39 you set |
If the web server restarts (e.g. web.config is updated) then how do I make the javascript client reconnect? The reconnection needs to try a few times until the server is back online.
The text was updated successfully, but these errors were encountered: