que 0.11.3 → 2.2.0

data/docs/advanced_setup.md

@@ -1,106 +0,0 @@
-## Advanced Setup
-
-### Using ActiveRecord Without Rails
-
-If you're using both Rails and ActiveRecord, the README describes how to get started with Que (which is pretty straightforward, since Que includes a Railtie that handles a lot of setup for you). Otherwise, you'll need to do some manual setup.
-
-If you're using ActiveRecord outside of Rails, you'll need to tell Que to piggyback on its connection pool after you've connected to the database:
-
-```ruby
-ActiveRecord::Base.establish_connection(ENV['DATABASE_URL'])
-
-require 'que'
-Que.connection = ActiveRecord
-```
-
-Then you can queue jobs just as you would in Rails:
-
-```ruby
-ActiveRecord::Base.transaction do
-  @user = User.create(params[:user])
-  SendRegistrationEmail.enqueue :user_id => @user.id
-end
-```
-
-There are other docs to read if you're using [Sequel](https://github.com/chanks/que/blob/master/docs/using_sequel.md) or [plain Postgres connections](https://github.com/chanks/que/blob/master/docs/using_plain_connections.md) (with no ORM at all) instead of ActiveRecord.
-
-### Forking Servers
-
-If you want to run a worker pool in your web process and you're using a forking webserver like Phusion Passenger (in smart spawning mode), Unicorn or Puma in some configurations, you'll want to set `Que.mode = :off` in your application configuration and only start up the worker pool in the child processes after the DB connection has been reestablished. So, for Puma:
-
-```ruby
-# config/puma.rb
-on_worker_boot do
-  ActiveRecord::Base.establish_connection
-
-  Que.mode = :async
-end
-```
-
-And for Unicorn:
-
-```ruby
-# config/unicorn.rb
-after_fork do |server, worker|
-  ActiveRecord::Base.establish_connection
-
-  Que.mode = :async
-end
-```
-
-And for Phusion Passenger:
-
-```ruby
-# config.ru
-if defined?(PhusionPassenger)
-  PhusionPassenger.on_event(:starting_worker_process) do |forked|
-    if forked
-      Que.mode = :async
-    end
-  end
-end
-```
-
-If there's other setup you want to do for workers, such as setting up the
-configuration, you'll need to do that manually as well.
-
-### Managing the Jobs Table
-
-After you've connected Que to the database, you can manage the jobs table:
-
-```ruby
-# Create/update the jobs table to the latest schema version:
-Que.migrate!
-```
-
-You'll want to migrate to a specific version if you're using migration files, to ensure that they work the same way even when you upgrade Que in the future:
-
-```ruby
-# Update the schema to version #3.
-Que.migrate! :version => 3
-
-# To reverse the migration, drop the jobs table entirely:
-Que.migrate! :version => 0
-```
-
-There's also a helper method to clear all jobs from the jobs table:
-
-```ruby
-Que.clear!
-```
-
-### Other Setup
-
-You'll need to set Que's mode manually:
-
-```ruby
-# Start the worker pool:
-Que.mode = :async
-
-# Or, when testing:
-Que.mode = :sync
-```
-
-Be sure to read the docs on [managing workers](https://github.com/chanks/que/blob/master/docs/managing_workers.md) for more information on using the worker pool.
-
-You'll also want to set up [logging](https://github.com/chanks/que/blob/master/docs/logging.md) and an [error handler](https://github.com/chanks/que/blob/master/docs/error_handling.md) to track errors raised by jobs.

data/docs/customizing_que.md

@@ -1,200 +0,0 @@
-## Customizing Que
-
-One of Que's goals to be easily extensible and hackable (and if anyone has any suggestions on ways to accomplish that, please [open an issue](https://github.com/chanks/que/issues)). This document is meant to demonstrate some of the ways Que can be used to accomplish different tasks that it's not already designed for.
-
-Some of these features may be moved into core Que at some point, depending on how commonly useful they are.
-
-### Recurring Jobs
-
-Que's support for scheduling jobs makes it easy to implement reliable recurring jobs. For example, suppose you want to run a job every hour that processes the users created in that time:
-
-```ruby
-class CronJob < Que::Job
-  # Default repetition interval in seconds. Can be overridden in
-  # subclasses. Can use 1.minute if using Rails.
-  INTERVAL = 60
-
-  attr_reader :start_at, :end_at, :run_again_at, :time_range
-
-  def _run
-    args = attrs[:args].first
-    @start_at, @end_at = Time.at(args.delete('start_at')), Time.at(args.delete('end_at'))
-    @run_again_at = @end_at + self.class::INTERVAL
-    @time_range = @start_at...@end_at
-
-    super
-
-    args['start_at'] = @end_at.to_f
-    args['end_at']   = @run_again_at.to_f
-    self.class.enqueue(args, run_at: @run_again_at)
-  end
-end
-
-class MyCronJob < CronJob
-  INTERVAL = 3600
-
-  def run(args)
-    User.where(created_at: time_range).each { ... }
-  end
-end
-
-# To enqueue:
-tf = Time.now
-t0 = Time.now - 3600
-MyCronJob.enqueue :start_at => t0.to_f, :end_at => tf.to_f
-```
-
-Note that instead of using Time.now in our database query, and requeueing the job at 1.hour.from_now, we use job arguments to track start and end times. This lets us correct for delays in running the job. Suppose that there's a backlog of priority jobs, or that the worker briefly goes down, and this job, which was supposed to run at 11:00 a.m. isn't run until 11:05 a.m. A lazier implementation would look for users created after 1.hour.ago, and miss those that signed up between 10:00 a.m. and 10:05 a.m.
-
-This also compensates for clock drift. `Time.now` on one of your application servers may not match `Time.now` on another application server may not match `now()` on your database server. The best way to stay reliable is have a single authoritative source on what the current time is, and your best source for authoritative information is always your database (this is why Que uses Postgres' `now()` function when locking jobs, by the way).
-
-Note also the use of the triple-dot range, which results in a query like `SELECT "users".* FROM "users" WHERE ("users"."created_at" >= '2014-01-08 10:00:00.000000' AND "users"."created_at" < '2014-01-08 11:00:00.000000')` instead of a BETWEEN condition. This ensures that a user created at 11:00 am exactly isn't processed twice, by the jobs starting at both 10 am and 11 am.
-
-Finally, by passing both the start and end times for the period to be processed, and only using the interval to calculate the period for the following job, we make it easy to change the interval at which the job runs, without the risk of missing or double-processing any users.
-
-### DelayedJob-style Jobs
-
-DelayedJob offers a simple API for delaying methods to objects:
-
-```ruby
-@user.delay.activate!(@device)
-```
-
-The API is pleasant, but implementing it requires storing marshalled Ruby objects in the database, which is both inefficient and prone to bugs - for example, if you deploy an update that changes the name of an instance variable (a contained, internal change that might seem completely innocuous), the marshalled objects in the database will retain the old instance variable name and will behave unexpectedly when unmarshalled into the new Ruby code.
-
-This is the danger of mixing the ephemeral state of a Ruby object in memory with the more permanent state of a database row. The advantage of Que's API is that, since your arguments are forced through a JSON serialization/deserialization process, it becomes your responsibility when designing a job class to establish an API for yourself (what the arguments to the job are and what they mean) that you will have to stick to in the future.
-
-That said, if you want to queue jobs in the DelayedJob style, that can be done relatively easily:
-
-```ruby
-class Delayed < Que::Job
-  def run(receiver, method, args)
-    Marshal.load(receiver).send method, *Marshal.load(args)
-  end
-end
-
-class DelayedAction
-  def initialize(receiver)
-    @receiver = receiver
-  end
-
-  def method_missing(method, *args)
-    Delayed.enqueue Marshal.dump(@receiver), method, Marshal.dump(args)
-  end
-end
-
-class Object
-  def delay
-    DelayedAction.new(self)
-  end
-end
-```
-
-You can replace Marshal with YAML if you like.
-
-### QueueClassic-style Jobs
-
-You may find it a hassle to keep an individual class file for each type of job. QueueClassic has a simpler design, wherein you simply give it a class method to call, like:
-
-```ruby
-QC.enqueue("Kernel.puts", "hello world")
-```
-
-You can mimic this style with Que by using a simple job class:
-
-```ruby
-class Command < Que::Job
-  def run(method, *args)
-    receiver, message = method.split('.')
-    Object.const_get(receiver).send(message, *args)
-  end
-end
-
-# Then:
-
-Command.enqueue "Kernel.puts", "hello world"
-```
-
-### Retaining Finished Jobs
-
-Que deletes jobs from the queue as they are worked, in order to keep the `que_jobs` table and index small and efficient. If you have a need to hold onto finished jobs, the recommended way to do this is to add a second table to hold them, and then insert them there as they are deleted from the queue. You can use Ruby's inheritance mechanics to do this cleanly:
-
-```ruby
-Que.execute "CREATE TABLE finished_jobs AS SELECT * FROM que_jobs LIMIT 0"
-# Or, better, use a proper CREATE TABLE with not-null constraints, and add whatever indexes you like.
-
-class MyJobClass < Que::Job
-  def destroy
-    Que.execute "INSERT INTO finished_jobs SELECT * FROM que_jobs WHERE queue = $1::text AND priority = $2::integer AND run_at = $3::timestamptz AND job_id = $4::bigint", @attrs.values_at(:queue, :priority, :run_at, :job_id)
-    super
-  end
-end
-```
-
-Then just have your job classes inherit from MyJobClass instead of Que::Job. If you need to query the jobs table and you want to include both finished and unfinished jobs, you might use:
-
-```ruby
-Que.execute "CREATE VIEW all_jobs AS SELECT * FROM que_jobs UNION ALL SELECT * FROM finished_jobs"
-Que.execute "SELECT * FROM all_jobs"
-```
-
-Alternately, if you want a more foolproof solution and you're not scared of PostgreSQL, you can use a trigger:
-
-```sql
-CREATE FUNCTION please_save_my_job()
-RETURNS trigger
-LANGUAGE plpgsql
-AS $$
-  BEGIN
-    INSERT INTO finished_jobs SELECT (OLD).*;
-    RETURN OLD;
-  END;
-$$;
-
-CREATE TRIGGER keep_all_my_old_jobs BEFORE DELETE ON que_jobs FOR EACH ROW EXECUTE PROCEDURE please_save_my_job();
-```
-
-### Not Retrying Certain Failed Jobs
-
-By default, when jobs fail, Que reschedules them to be retried later. If instead you'd like certain jobs to not be retried, and instead move them elsewhere to be examined later, you can accomplish that easily. First, we need a place for the failed jobs to be stored:
-
-```sql
-CREATE TABLE failed_jobs AS SELECT * FROM que_jobs LIMIT 0
-```
-
-Then, create a module that you can use in the jobs you don't want to retry:
-
-```ruby
-module SkipRetries
-  def run(*args)
-    super
-  rescue
-    sql = <<-SQL
-      WITH failed AS (
-        DELETE
-        FROM   que_jobs
-        WHERE  queue    = $1::text
-        AND    priority = $2::smallint
-        AND    run_at   = $3::timestamptz
-        AND    job_id   = $4::bigint
-        RETURNING *
-      )
-      INSERT INTO failed_jobs
-        SELECT * FROM failed;
-    SQL
-
-    Que.execute sql, @attrs.values_at(:queue, :priority, :run_at, :job_id)
-
-    raise # Reraises caught error.
-  end
-end
-
-class RunOnceJob < Que::Job
-  prepend SkipRetries
-
-  def run(*args)
-    # Do something - if this job runs an error it'll be moved to the
-    # failed_jobs table and not retried.
-  end
-end
-```

data/docs/error_handling.md

@@ -1,47 +0,0 @@
-## Error Handling
-
-If an error is raised and left uncaught by your job, Que will save the error message and backtrace to the database and schedule the job to be retried later.
-
-If a given job fails repeatedly, Que will retry it at exponentially-increasing intervals equal to (failure_count^4 + 3) seconds. This means that a job will be retried 4 seconds after its first failure, 19 seconds after its second, 84 seconds after its third, 259 seconds after its fourth, and so on until it succeeds. This pattern is very similar to DelayedJob's. Alternately, you can define your own retry logic by setting an interval to delay each time, or a callable that accepts the number of failures and returns an interval:
-
-```ruby
-class MyJob < Que::Job
-  # Just retry a failed job every 5 seconds:
-  @retry_interval = 5
-
-  # Always retry this job immediately (not recommended, or transient
-  # errors will spam your error reporting):
-  @retry_interval = 0
-
-  # Increase the delay by 30 seconds every time this job fails:
-  @retry_interval = proc { |count| count * 30 }
-end
-```
-
-Unlike DelayedJob, however, there is currently no maximum number of failures after which jobs will be deleted. Que's assumption is that if a job is erroring perpetually (and not just transiently), you will want to take action to get the job working properly rather than simply losing it silently.
-
-If you're using an error notification system (highly recommended, of course), you can hook Que into it by setting a callable as the error handler:
-
-```ruby
-Que.error_handler = proc do |error, job|
-  # Do whatever you want with the error object or job row here.
-
-  # Note that the job passed is not the actual job object, but the hash
-  # representing the job row in the database, which looks like:
-
-  # {
-  #   "queue" => "my_queue",
-  #   "priority" => 100,
-  #   "run_at" => 2015-03-06 11:07:08 -0500,
-  #   "job_id" => 65,
-  #   "job_class" => "MyJob",
-  #   "args" => ['argument', 78],
-  #   "error_count" => 0
-  # }
-
-  # This is done because the job may not have been able to be deserialized
-  # properly, if the name of the job class was changed or the job is being
-  # retrieved and worked by the wrong app. The job argument may also be
-  # nil, if there was a connection failure or something similar.
-end
-```

data/docs/inspecting_the_queue.md

@@ -1,114 +0,0 @@
-## Inspecting the Queue
-
-In order to remain simple and compatible with any ORM (or no ORM at all), Que is really just a very thin wrapper around some raw SQL. There are two methods available that query the jobs table and Postgres' system catalogs to retrieve information on the current state of the queue:
-
-### Job Stats
-
-You can call `Que.job_stats` to return some aggregate data on the types of jobs currently in the queue. Example output:
-
-```ruby
-[
-  {
-    "job_class"=>"ChargeCreditCard",
-    "count"=>"10",
-    "count_working"=>"4",
-    "count_errored"=>"2",
-    "highest_error_count"=>"5",
-    "oldest_run_at"=>"2014-01-04 21:24:55.817129+00"
-  },
-  {
-    "job_class"=>"SendRegistrationEmail",
-    "count"=>"8",
-    "count_working"=>"0",
-    "count_errored"=>"0",
-    "highest_error_count"=>"0",
-    "oldest_run_at"=>"2014-01-04 22:24:55.81532+00"
-  }
-]
-```
-
-This tells you that, for instance, there are ten ChargeCreditCard jobs in the queue, four of which are currently being worked, and two of which have experienced errors. One of them has started to process but experienced an error five times. The oldest_run_at is helpful for determining how long jobs have been sitting around, if you have backlog.
-
-### Worker States
-
-You can call `Que.worker_states` to return some information on every worker touching the queue (not just those in the current process). Example output:
-
-```ruby
-[
-  {
-    "priority"=>"2",
-    "run_at"=>"2014-01-04 22:35:55.772324+00",
-    "job_id"=>"4592",
-    "job_class"=>"ChargeCreditCard",
-    "args"=>"[345,56]",
-    "error_count"=>"0",
-    "last_error"=>nil,
-    "pg_backend_pid"=>"1175",
-    "pg_state"=>"idle",
-    "pg_state_changed_at"=>"2014-01-04 22:35:55.777785+00",
-    "pg_last_query"=>"SELECT * FROM users",
-    "pg_last_query_started_at"=>"2014-01-04 22:35:55.777519+00",
-    "pg_transaction_started_at"=>nil,
-    "pg_waiting_on_lock"=>"f"
-  }
-]
-```
-
-In this case, there is only one worker currently working the queue. The first seven fields are the attributes of the job it is currently running. The next seven fields are information about that worker's Postgres connection, and are taken from `pg_stat_activity` - see [Postgres' documentation](http://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW) for more information on interpreting these fields.
-
-* `pg_backend_pid` - The pid of the Postgres process serving this worker. This is useful if you wanted to kill that worker's connection, for example, by running "SELECT pg_terminate_backend(1175)". This would free up the job to be attempted by another worker.
-* `pg_state` - The state of the Postgres backend. It may be "active" if the worker is currently running a query or "idle"/"idle in transaction" if it is not. It may also be in one of a few other less common states.
-* `pg_state_changed_at` - The timestamp for when the backend's state was last changed. If the backend is idle, this would reflect the time that the last query finished.
-* `pg_last_query` - The text of the current or most recent query that the worker sent to the database.
-* `pg_last_query_started_at` - The timestamp for when the last query began to run.
-* `pg_transaction_started_at` - The timestamp for when the worker's current transaction (if any) began.
-* `pg_waiting_on_lock` - Whether or not the worker is waiting for a lock in Postgres to be released.
-
-### Custom Queries
-
-If you want to query the jobs table yourself to see what's been queued or to check the state of various jobs, you can always use Que to execute whatever SQL you want:
-
-```ruby
-Que.execute("select count(*) from que_jobs") #=> [{"count"=>"492"}]
-```
-
-If you want to use ActiveRecord's features when querying, you can define your own model around Que's job table:
-
-```ruby
-class QueJob < ActiveRecord::Base
-end
-
-# Or:
-
-class MyJob < ActiveRecord::Base
-  self.table_name = :que_jobs
-end
-```
-
-Then you can query just as you would with any other model. Since the jobs table has a composite primary key, however, you probably won't be able to update or destroy jobs this way, though.
-
-If you're using Sequel, you can use the same technique:
-
-```ruby
-class QueJob < Sequel::Model
-end
-
-# Or:
-
-class MyJob < Sequel::Model(:que_jobs)
-end
-```
-
-And note that Sequel *does* support composite primary keys:
-
-```ruby
-job = QueJob.where(:job_class => "ChargeCreditCard").first
-job.priority = 1
-job.save
-```
-
-Or, you can just use Sequel's dataset methods:
-
-```ruby
-DB[:que_jobs].where{priority > 3}.all
-```

data/docs/logging.md

@@ -1,50 +0,0 @@
-## Logging
-
-By default, Que logs important information in JSON to either Rails' logger (when running in a Rails web process) or STDOUT (when running via the `que` executable). So, your logs will look something like:
-
-```
-I, [2014-01-12T05:07:31.094201 #4687]  INFO -- : {"lib":"que","thread":104928,"event":"job_worked","elapsed":0.01045,"job":{"priority":"1","run_at":"2014-01-12 05:07:31.081877+00","job_id":"4","job_class":"MyJob","args":[],"error_count":"0"}}
-```
-
-Of course you can have it log wherever you like:
-
-```ruby
-Que.logger = Logger.new(...)
-```
-
-You can use Que's logger in your jobs anywhere you like:
-
-```ruby
-class MyJob
-  def run
-    Que.log :my_output => "my string"
-  end
-end
-
-#=> I, [2014-01-12T05:13:11.006776 #4914]  INFO -- : {"lib":"que","thread":24960,"my_output":"my string"}
-```
-
-Que will always add a 'lib' key, so you can easily filter its output from that of other sources, and the object_id of the thread that emitted the log, so you can follow the actions of a particular worker if you wish. You can also pass a :level key to set the level of the output:
-
-```ruby
-Que.log :level => :debug, :my_output => 'my string'
-#=> D, [2014-01-12T05:16:15.221941 #5088] DEBUG -- : {"lib":"que","thread":24960,"my_output":"my string"}
-```
-
-If you don't like JSON, you can also customize the format of the logging output by passing a callable object (such as a proc) to Que.log_formatter=. The proc should take a hash (the keys are symbols) and return a string. The keys and values are just as you would expect from the JSON output:
-
-```ruby
-Que.log_formatter = proc do |data|
-  "Thread number #{data[:thread]} experienced a #{data[:event]}"
-end
-```
-
-If the log formatter returns nil or false, a nothing will be logged at all. You could use this to narrow down what you want to emit, for example:
-
-```ruby
-Que.log_formatter = proc do |data|
-  if [:job_worked, :job_unavailable].include?(data[:event])
-    JSON.dump(data)
-  end
-end
-```

data/docs/managing_workers.md

@@ -1,80 +0,0 @@
-## Managing Workers
-
-Que provides a pool of workers to process jobs in a multithreaded fashion - this allows you to save memory by working many jobs simultaneously in the same process.
-
-When the worker pool is active (when you set `Que.mode = :async`), the default number of workers is 4. This is fine for most use cases, but the ideal number for your app will depend on your interpreter and what types of jobs you're running.
-
-Ruby MRI has a global interpreter lock (GIL), which prevents it from using more than one CPU core at a time. Having multiple workers running makes sense if your jobs tend to spend a lot of time in I/O (waiting on complex database queries, sending emails, making HTTP requests, etc.), as most jobs do. However, if your jobs are doing a lot of work in Ruby, they'll be spending a lot of time blocking each other, and having too many workers running will just slow everything down.
-
-JRuby and Rubinius, on the other hand, have no global interpreter lock, and so can make use of multiple CPU cores - you could potentially set the number of workers very high for them. You should experiment to find the best setting for your use case.
-
-You can change the number of workers in the pool whenever you like by setting the `worker_count` option:
-
-```ruby
-Que.worker_count = 8
-```
-
-### Working Jobs Via Executable
-
-If you don't want to burden your web processes with too much work and want to run workers in a background process instead, similar to how most other queues work, you can:
-
-```shell
-# Run a pool of 4 workers:
-que
-
-# Or configure the number of workers:
-que --worker-count 8
-```
-
-See `que -h` for a list of command-line options.
-
-### Thread-Unsafe Application Code
-
-If your application code is not thread-safe, you won't want any workers to be processing jobs while anything else is happening in the Ruby process. So, you'll want to turn the worker pool off by default:
-
-```ruby
-Que.mode = :off
-```
-
-This will prevent Que from trying to process jobs in the background of your web processes. In order to actually work jobs, you'll want to run a single worker at a time, and to do so via a separate process, like so:
-
-```shell
-que --worker-count 1
-```
-
-### The Wake Interval
-
-If a worker checks the job queue and finds no jobs ready for it to work, it will fall asleep. In order to make sure that newly-available jobs don't go unworked, a worker is awoken every so often to check for available work. By default, this happens every five seconds, but you can make it happen more or less often by setting a custom wake_interval:
-
-```ruby
-Que.wake_interval = 2 # In Rails, 2.seconds also works fine.
-```
-
-You can also choose to never let workers wake up on their own:
-
-```ruby
-# Never wake up any workers:
-Que.wake_interval = nil
-```
-
-If you do this, though, you'll need to wake workers manually.
-
-### Manually Waking Workers
-
-Regardless of the `wake_interval` setting, you can always wake workers manually:
-
-```ruby
-# Wake up a single worker to check the queue for work:
-Que.wake!
-
-# Wake up all workers in this process to check for work:
-Que.wake_all!
-```
-
-`Que.wake_all!` is helpful if there are no jobs available and all your workers go to sleep, and then you queue a large number of jobs. Typically, it will take a little while for the entire pool of workers get going again - a new one will wake up every `wake_interval` seconds, but it will take up to `wake_interval * worker_count` seconds for all of them to get going. `Que.wake_all!` can get them all moving immediately.
-
-### Connection Pool Size
-
-For the job locking system to work properly, each worker thread needs to reserve a database connection from the connection pool for the period of time between when it locks a job and when it releases that lock (which won't happen until the job has been finished and deleted from the queue).
-
-So, for example, if you're running 6 workers via the executable, you'll want to make sure that whatever connection pool Que is using (usually ActiveRecord's) has a maximum size of at least 6. If you're running those workers in a web process, you'll want the size to be at least 6 plus however many connections you expect your application to need for serving web requests (which may only be one if you're using Rails in single-threaded mode, or many more if you're running a threaded web server like Puma).

data/docs/migrating.md

@@ -1,30 +0,0 @@
-## Migrating
-
-Some new releases of Que may require updates to the database schema. It's recommended that you integrate these updates alongside your other database migrations. For example, when Que released version 0.6.0, the schema version was updated from 2 to 3. If you're running ActiveRecord, you could make a migration to perform this upgrade like so:
-
-```ruby
-class UpdateQue < ActiveRecord::Migration
-  def self.up
-    Que.migrate! :version => 3
-  end
-
-  def self.down
-    Que.migrate! :version => 2
-  end
-end
-```
-
-This will make sure that your database schema stays consistent with your codebase. If you're looking for something quicker and dirtier, you can always manually migrate in a console session:
-
-```ruby
-# Change schema to version 3.
-Que.migrate! :version => 3
-
-# Update to whatever the latest schema version is.
-Que.migrate!
-
-# Check your current schema version.
-Que.db_version #=> 3
-```
-
-Note that you can remove Que from your database completely by migrating to version 0.

data/docs/multiple_queues.md

@@ -1,27 +0,0 @@
-## Multiple Queues
-
-Que supports the use of multiple queues in a single job table. This feature is intended to support the case where multiple applications (with distinct codebases) are sharing the same database. For instance, you might have a separate Ruby application that handles only processing credit cards. In that case, you can run that application's workers against a specific queue:
-
-```shell
-que --queue-name credit_cards
-```
-
-Then you can set jobs to be enqueued in that queue specifically:
-
-```ruby
-ProcessCreditCard.enqueue current_user.id, :queue => 'credit_cards'
-
-# Or:
-
-class ProcessCreditCard < Que::Job
-  # Set a default queue for this job class; this can be overridden by
-  # passing the :queue parameter to enqueue like above.
-  @queue = 'credit_cards'
-end
-```
-
-In some cases, the ProcessCreditCard class may not be defined in the application that is enqueueing the job. In that case, you can specify the job class as a string:
-
-```ruby
-Que.enqueue current_user.id, :job_class => 'ProcessCreditCard', :queue => 'credit_cards'
-```

data/docs/shutting_down_safely.md

@@ -1,7 +0,0 @@
-## Shutting Down Safely
-
-To ensure safe operation, Que needs to be very careful in how it shuts down. When a Ruby process ends normally, it calls Thread#kill on any threads that are still running - unfortunately, if a thread is in the middle of a transaction when this happens, there is a risk that it will be prematurely commited, resulting in data corruption. See [here](http://blog.headius.com/2008/02/ruby-threadraise-threadkill-timeoutrb.html) and [here](http://coderrr.wordpress.com/2011/05/03/beware-of-threadkill-or-your-activerecord-transactions-are-in-danger-of-being-partially-committed/) for more detail on this.
-
-To prevent this, Que will block a Ruby process from exiting until all jobs it is working have completed normally. Unfortunately, if you have long-running jobs, this may take a very long time (and if something goes wrong with a job's logic, it may never happen). The solution in this case is SIGKILL - luckily, Ruby processes that are killed via SIGKILL will end without using Thread#kill on its running threads. This is safer than exiting normally - when PostgreSQL loses the connection it will simply roll back the open transaction, if any, and unlock the job so it can be retried later by another worker. Be sure to read [Writing Reliable Jobs](https://github.com/chanks/que/blob/master/docs/writing_reliable_jobs.md) for information on how to design your jobs to fail safely.
-
-So, be prepared to use SIGKILL on your Ruby processes if they run for too long. For example, Heroku takes a good approach to this - when Heroku's platform is shutting down a process, it sends SIGTERM, waits ten seconds, then sends SIGKILL if the process still hasn't exited. This is a nice compromise - it will give each of your currently running jobs ten seconds to complete, and any jobs that haven't finished by then will be interrupted and retried later.