Skip to content

An example of using redis and EM::Channel in Goliath for a long-polling interface

Notifications You must be signed in to change notification settings

jwarchol/redis_pubsub

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Redis PubSub with EM::Channel in Goliath

This example app uses Redis publish/subscribe channels to pass messages from an input source (input.rb) to the API clients via Goliath and EM::Channel. The idea is to have just one connection to Redis, rather than one per connection as seen in other examples. Within the context of one instance of this Goliath app, messages are further multiplexed to connected clients via Event Machine channels.

The current input example pings a remote host and passes the resulting ping output to the redis channel.

NOTE: Be sure you don't use em-synchrony's hiredis driver in the config file. The execution is on the root fiber there and em-synchrony will not like that. Using the regular EM hiredis driver lets that work happen on the reactor loop without causing any problems.

The only real trick here was doing some em-synchrony style fiber yielding and resuming in order to have the request wait until there is a message on the channel. This API is currently for a long-polling kind of interface. It could be extended for an HTTP stream.

Terminal #1

ruby redis_pubsub.rb -sv -e prod

Terminal #2

ruby input.rb

Then hit http://localhost:9000/index.html

About

An example of using redis and EM::Channel in Goliath for a long-polling interface

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages