Pollpole is a toy rails app that demonstrates background processing. A user can click on different examples that start a long running process. Then the app will demonstrate and print out the state of the the process with and without polling. The object is not to poll constantly for when the job is done. So in the spirit of not polling, there will be several “smarter” ways to do background jobs.
The PoleRace object is a contrived program that serves as a unit of work to be done. It’s complex enough to be more interesting than a sleep but not so complex that it subtracts from the job queuing focus of this app. PoleRace is the race activity itself. It has a racer and a judge. When the race is started, the judge observes the racer. When the racer completes climbing the pole, they ring a bell and that notifies the Judge that the race is over. The judge stops their watch and the race time is stored.
Interestingly, the Judge time is slightly longer than the real system time of the race because of the update method call. The race, judge and racer objects are all in the extras directory, autoloaded as libraries and would print their output to STDOUT if you ran them in the rails console.
In the cases where the PoleRace is scheduled in the job queue, care must be taken to ensure that unpopulated fields are not used too soon. For example, the race will not have a time until it is completed. In asynchronous cases, the browser will not know when the race is done unless they watch for the scores being posted.
So in summary, the logical ordering of events goes something like this:
-
A race is created by the browser (client).
-
The browser starts a polling watch to check for jobs (js timer and ajax).
-
A judge watches a racer (from a Ruby perspective).
-
A racer takes some time to climb a pole (random sleep).
-
The judge sees the racer finish and records the time.
-
The judge posts the time (to a database).
-
When the client sees no job anymore, the race must be done.
-
The client timer stops and the client fetches the score (in JSON format).
-
The client updates the DOM with the score data.
Each of these processes can be backgrounded. In other words, some will run in the browser request. However, the more typical thing to do is to background the process with delayed_job or equivalent. In this case, the browser won’t be able to poll state. Because of this, we will have to listen to a channel to wait for the status of the job (faye).
The tricky part is going to be wiring up the backend to the browser. Faye may make this easier but something like delayed_job will not. I have a feeling that browser polling will be needed for that example and probably beanstalkd.
In the end, it will practice:
-
faye
-
ajax
-
delayed_job (again)
-
beanstalkd
-
redis + girl_friday/resque
-
job scheduling abstraction (although easy with delayed_job, would be nice
to write this cleanly)
For all demos:
> bundle > rails s
For the delayed job demo, start this in a new shell:
> rake jobs:work
For the faye demo, start this in a new shell:
> rackup private_pub.ru -E production # Unfortunately, production mode is needed otherwise you'll get Rack::Lint::LintError: Status must be >=100 seen as integer
-
All monkey patches are in config/initializers/monkey_patches.rb