librelist archives

Re: [sunshowers] Push functionality

From:

Eric Wong

Date:

2010-01-04 @ 22:18

Thomas Sommer <thomas.sommer@tricycledevelopments.com> wrote:
> > >       @app.configure do
> > >         WebsocketIo.setup ws_io
> > >       end
> >
> > Huh?  I'm not sure you need to do @app.configure for every single
> > request that comes in.
> >
> > > Thats all good and fine... with the #configure call above the IO object
> > is
> > > made available to the Sinatra app, so that solves my original problem.
> >
> > That @app.configure call appears to app-wide, but you're localizing to
> > a certain HTTP request which seems wrong.
> 
> Yes, this part is not even close to being good, but that was my first (lazy)
> attempt to make the WebSocket IO object available to stuff that happens
> outside of the WS request.
> 
> I'll explain my situation: My Sinatra app is connected to our MPD server in
> the office. The connection gets status updates from the server (eg. current
> song, elapsed time etc). This connection is just a class thats required from
> the Sinatra app and regular HTTP requests then poll the data from this
> Proxy. What i'm ultimately trying to do, is to push out the updates (to the
> browsers) from the Proxy class as soon as they arrive... but for this to
> happen i have to access the WS IO (or Request) object from 'outside' without
> having to be stuck between the #handshake! and #quit! calls in the
> WebSocketHandler...

Ah, which MPD module are you using?  Am I correct you're trying to
share the output from one MPD connection to multiple clients?

Yes, than you'd have to be registering the ws_io with some central
dispatcher...  For Sunshowers, I'd imagine you'd need a background
thread/fiber reading the MPD socket and writing:

  @@clients = []

  def self.register(ws_io)
    @@clients << ws_io
  end

  # This could be a Thread instead of a Fiber too,
  #  depending on your concurrency model
  Fiber.spawn do
    @@mpd_sock.each_line do |line|
      @@clients.delete_if do |ws_io|
        begin
          ws_io.write_utf8(line)
          false # do not delete on success
        rescue # something went wrong, client probably disconnected
          ws_io.ws_quit!
          true # delete
        end
      end
    end
  end

I'm not sure how Sunshowers will work with EventMachine/Rev/Reactor
concurrency models.  But this is probably one of those cases where
programming using an explicitly evented model is actually easier than
using a synchronous concurrency model...

> > > Of course theres a new problem (actually theres more than one) now ;)
> > When i
> > > start up Rainbows! it:
> > > 1. Takes forever (about 30 sec) to initialize the worker... in the
> > command
> > > line it hangs a bit when it says 'Refreshing Gem list'.
> >
> > That doesn't sound right, which Rainbows! concurrency model are you using?
> > Of course, it could be the lack of @app.configure being called at the
> > top-level...
> 
> Its not the #configure call... that happened w/o the call as well.
> How can i find out about the concurrency model im using?

I guess you didn't configure it at all :) In your Rainbows!/Unicorn
config file, it's just having:

      Rainbows! do
        use concurrency_model
      end

Currently, only the following concurrency models are supported

* :FiberSpawn
* :FiberPool
* :Revactor
* :ThreadSpawn
* :ThreadPool
* :RevFiberSpawn

There'll be more, and I'll update
http://rainbows.rubyforge.org/sunshowers/ to reflect that.  Keep in mind
that Ruby 1.8 can only use the Thread* models, not the Fiber ones.
Note that in the above example, with MPD, I used a Fiber.  Just replace
it with a Thread if you choose a Thread-based concurrency model because
Fibers are not shareable across Threads.

> > > 2. Rainbows! really needs a long time to load up static content (images,
> > > stylesheets, ...)
> >
> > Do you cache that stuff ahead of time?  Exactly how much is loaded?
> > It should behave like other Rack servers.
> 
> Theres no caching, and im pretty sure Rainbows! should be used together with
> a regular web server (ie apache). I just found that it loads up the stuff
> way slower in comparison to eg. thin...

It could be the lack of a configured concurrency model, but Rainbows!
shouldn't be slower than Thin for static files.  This is all on a LAN?
Apache will definitely be faster for static files (on a LAN), though it
may not matter for most use cases...  Of course outside of a LAN on slow
networks nginx/lighttpd will beat Apache (not sure if Apache mpm_event
came to anything usable...).

-- 
Eric Wong

>
>
> Ah, which MPD module are you using?  Am I correct you're trying to
> share the output from one MPD connection to multiple clients?
>
> Yes, than you'd have to be registering the ws_io with some central
> dispatcher...  For Sunshowers, I'd imagine you'd need a background
> thread/fiber reading the MPD socket and writing:
>
>  @@clients = []
>
>  def self.register(ws_io)
>    @@clients << ws_io
>  end
>
>  # This could be a Thread instead of a Fiber too,
>  #  depending on your concurrency model
>  Fiber.spawn do
>    @@mpd_sock.each_line do |line|
>      @@clients.delete_if do |ws_io|
>        begin
>          ws_io.write_utf8(line)
>          false # do not delete on success
>        rescue # something went wrong, client probably disconnected
>          ws_io.ws_quit!
>          true # delete
>        end
>      end
>    end
>  end
>
> I'm not sure how Sunshowers will work with EventMachine/Rev/Reactor
> concurrency models.  But this is probably one of those cases where
> programming using an explicitly evented model is actually easier than
> using a synchronous concurrency model...
>

First of all: AWESOME!!!
This mail did it for me. The main thing was the configuration part - having
Rainbows unconfigured is not a good idea ;) Heres the code i ended up with:


config.ru
(as before)


websocket_handler:

require 'sunshowers'
class WebsocketHandler
  def initialize(app)
    @app = app
  end

  def call(env)
    req = Sunshowers::Request.new(env)

    if req.ws?
      req.ws_handshake!
      WebsocketIo.register req

      ws_io = req.ws_io
      ws_io.each { } # no-op
      req.ws_quit!

      [404, {}, []]
    else
      status, headers, body = @app.call(env)
      [status, headers, body]
    end
  end
end


websocket_io:

class WebsocketIo
  @req_list = []

  class << self
    def register(req)
      @req_list << req
    end

    def write(message)
      @req_list.each do |req|
        begin
          req.ws_io.write message
        rescue Exception => e
          req.ws_quit!
        end
      end
    end
  end
end


This code still needs some sanity checking and some error handling but it
works. Now, whenever im calling WebsocketIo.write from anywhere in my app it
pushes out to all the connected Websockets.

BTW, im using librmpd for MPD, which 'pushes' updates to my proxy inside the
sinatra app.


> > > > Of course theres a new problem (actually theres more than one) now ;)
> > > When i
> > > > start up Rainbows! it:
> > > > 1. Takes forever (about 30 sec) to initialize the worker... in the
> > > command
> > > > line it hangs a bit when it says 'Refreshing Gem list'.
> > >
> > > That doesn't sound right, which Rainbows! concurrency model are you
> using?
> > > Of course, it could be the lack of @app.configure being called at the
> > > top-level...
> >
> > Its not the #configure call... that happened w/o the call as well.
> > How can i find out about the concurrency model im using?
>
> I guess you didn't configure it at all :) In your Rainbows!/Unicorn
> config file, it's just having:
>
>      Rainbows! do
>        use concurrency_model
>      end
>
> <snip>

>
> It could be the lack of a configured concurrency model, but Rainbows!
> shouldn't be slower than Thin for static files.  This is all on a LAN?
> Apache will definitely be faster for static files (on a LAN), though it
> may not matter for most use cases...  Of course outside of a LAN on slow
> networks nginx/lighttpd will beat Apache (not sure if Apache mpm_event
> came to anything usable...).
>

So, it has been all about the config. Could it be that Rainbows just handles
1 connection by default? If thats true then the Websocket did block
everything else (of course). The speed has also improved drastically!

Heres the config im using now:

worker_processes 2
Rainbows! do
  use :ThreadSpawn
  worker_connections 10
end

Are there any guidelines on how many connections one should use?

Thanks mate, I owe u a beer!
Tom

Thomas Sommer <thomas.sommer@tricycledevelopments.com> wrote:
> First of all: AWESOME!!!
> This mail did it for me. The main thing was the configuration part - having
> Rainbows unconfigured is not a good idea ;) Heres the code i ended up with:

Cool, good to know everything worked out for you :)

> So, it has been all about the config. Could it be that Rainbows just handles
> 1 connection by default? If thats true then the Websocket did block
> everything else (of course). The speed has also improved drastically!

Yup, the Rainbows! defaults are very conservative, one worker, one
connection.  I've considered setting more aggressive ones, but
given the large variety of apps out there, it's _always_ broken for
someone, and sometimes the problem wouldn't get noticed until it's
too late.

> Heres the config im using now:
> 
> worker_processes 2
> Rainbows! do
>   use :ThreadSpawn
>   worker_connections 10
> end
> 
> Are there any guidelines on how many connections one should use?

It depends on the type of traffic you get.  If it's just your
office/LAN, then just count the number of clients you expect connected
at any given time.

Keep in mind the real number of connections is
(worker_processes * worker_connections)

> Thanks mate, I owe u a beer!

No problem.  You don't owe me anything, I don't drink :)

-- 
Eric Wong