Reconnect client after server restart about signalr

[davidfowl]

What exactly doesn't work? Are you persisting messages to a database or keeping everything in memory?

[andrewdavey]

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.

[davidfowl]

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.

[davidfowl]

Try this out https://gist.github.com/1207068

[davidfowl]

I'll add this feature to our default message, in memory message store.

[andrewdavey]

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?

[andrewdavey]

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
Scratch that, it's still going into a loop. I'll keep digging...

[andrewdavey]

Another approach: offset the message IDs sent to the client (gist updated https://gist.github.com/1208346 )
This seems to work now. Are there any nasty side effects of doing this?

[davidfowl]

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.

[davidfowl]

Fixed in 29e5768

[andrewdavey]

Perfect, thanks David.

I'll get my CSS auto-reloading utility up on nuget soon, once the SignalR package is updated.

[andrewdavey]

It's online!

Install-Package ExpressCss

https://github.com/andrewdavey/expresscss

[akoeplinger]

There seems to be a regression of this issue in the current version.
If I start the server, broadcast some messages to the connected clients (so they're e.g. at last message id = 30) and then restart the server, I need to broadcast 31 messages before the clients catch up again.

[davidfowl]

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 )

[akoeplinger]

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:

1. Launch the server.exe
2. Launch the client.exe
3. Press enter or another key a few times inside the server to broadcast a message to the client. It should output a counter on both apps.
4. Close the server
5. Open the server again and wait a short time for the client to reconnect.
6. Press enter again a few times inside the server. It will not output anything on the client (but it should) until you are at the same count. When you reach the count, pressing enter in the server immediately outputs a message on the client as expected.

I guess the regression happened after InProcessMessageStore.cs was refactored into InProcessMessageBus.cs

Let me know if you need additional details ;-)

[akoeplinger]

Ok, I think I've found the issue.
In https://github.com/SignalR/SignalR/blob/master/SignalR/MessageBus/InProcessMessageBus.cs#L105 you compare the stored id with the id the client requests. By handling the result with >= 0, ids that are bigger than the stored _lastMessageId are recognized as if the client had the latest message.
There should be a seperate if that checks for bigger ids and responds with the stored _lastMessageId.

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 ;-)

[davidfowl]

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.

[akoeplinger]

There is a small glitch with the trace information output. In 1d6ce39 you set uuid = default(T), but the id parameter is left unchanged.
So it outputs a wrong trace message, e.g. "Connection waiting for new messages from id 27" when it is in fact waiting from id 0. Consider using uuid instead of id in the trace messages.