websocket-rails/websocket-rails — pull request #171 by lkol (2013-12-12 11:39:40+00:00)
Title: Added a possibility to set channel success and failure callbacks on subs...

I experienced a strange problem, when I deployed my app to production and had to switch to standalone server mode with Redis. For some reason, I was unable to handle channel events using the Javascript API, although I had set handler functions with ```channel.bind``` function and everything worked with Thin in my development environment. The bug seemed random, as every now and then everything worked as supposed to.

After some digging, I found out that the problem must be related to the way I bind the handlers:
```coffeescript
@dispatcher.on_open = @bindEvents

bindEvents: =>
channel = @dispatcher.subscribe_private @channelId
channel.bind 'message', @handleEvents
```

If this operation was performed too quickly after dispatcher was opened, the problem would occur. A problem could be bypassed to a degree by adding a delay to bindEvents call.

A better solution would be to bind the channel events only after the channel has been successfully set up, using the on_success callback:
```coffeescript
bindEvents: =>
channel = @dispatcher.subscribe_private @channelId, =>
channel.bind 'message', @handleEvents
```

Going through channels.js.coffee, it seemed that on_success and on_failure callbacks were completely useless, as they are only called in the constructor for the subscribe event, but could be only set after the object has been constructed. So I modified the classes to allow passing the callbacks on @dispatcher.subscribe (channel construction). This solved my problem.

I still don't know what's the reason why this only occurs in standalone server mode, though.