que 0.11.2 → 0.11.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 20a82205491645e72a518cdf75314214732d7592
-  data.tar.gz: 35abbe3fbb3f8b8f43dcc3fb5c62eeb09fd2de36
+  metadata.gz: 36663fa76366e576b7da98780e9c71519148fc10
+  data.tar.gz: dd37b18e13b152b2f2f876439b491ec3820465a4
 SHA512:
-  metadata.gz: 21344fb8e7a6e0548cef67e9c8b27e439deb13588b9e94d2d0575ca63f8c5999f11960d2e81de5813f5208fd7fe39c364919bc0f41742470ab7a83466f1d3197
-  data.tar.gz: d93fda616f7efb5d05d7c02352aa0c3dab32dcb525400854b706827d977ccca7d61d5f2052ac046872540b98917f3f78e5baddded650c99c735cb2b3c8faecc3
+  metadata.gz: f6d752b03080ae3d1a04b3afdf21b886a9d615011d38d713015c47aadd1f389bb231ed9d553b4c7beba382bbdfbeda97510d7212debc527f6f6daedef074b646
+  data.tar.gz: 7e087a89f476a2fefe2426e1d9d6143045748cda09fb61254ee0645d670583a74f4bef137bf13cc04f232e45ccfc6d91c7e0337e6b4ab004aed88aadd0a48702

data/.travis.yml

@@ -3,6 +3,8 @@ rvm:
   - "1.9.3"
   - "2.0"
   - "2.1"
+  - "2.2"
+  - "2.3"
   - "rbx-2"
   - "jruby-1.7.5"
 before_script:

data/CHANGELOG.md

@@ -1,3 +1,13 @@
+### 0.11.3 (2016-02-26)
+
+*   Fixed bug with displaying the current version of the que executable. (#122) (hardbap)
+
+*   Output to STDOUT when running via the executable or rake task is no longer buffered. This prevented logging in some cases. (#129) (hmarr)
+
+*   Officially added support for Ruby 2.2 and 2.3.
+
+*   String literals are now frozen on Ruby 2.3.
+
 ### 0.11.2 (2015-09-09)
 
 *   Fix Job class constantizing when ActiveSupport isn't loaded. (#121) (godfat)

data/README.md

@@ -100,8 +100,8 @@ ChargeCreditCard.enqueue current_user.id, :credit_card_id => card.id, :run_at =>
 
 To determine what happens when a job is queued, you can set Que's mode. There are a few options for the mode:
 
-  * `Que.mode = :off` - In this mode, queueing a job will simply insert it into the database - the current process will make no effort to run it. You should use this if you want to use a dedicated process to work tasks (there's a rake task included that will do this, `rake que:work`). This is the default when running `bin/rails console`.
-  * `Que.mode = :async` - In this mode, a pool of background workers is spun up, each running in their own thread. This is the default when running `bin/rails server`. See the docs for [more information on managing workers](https://github.com/chanks/que/blob/master/docs/managing_workers.md).
+  * `Que.mode = :off` - In this mode, queueing a job will simply insert it into the database - the current process will make no effort to run it. You should use this if you want to use a dedicated process to work tasks (there's an executable included that will do this, `que`). This is the default when running `bin/rails console`.
+  * `Que.mode = :async` - In this mode, a pool of background workers is spun up, each running in their own thread. See the docs for [more information on managing workers](https://github.com/chanks/que/blob/master/docs/managing_workers.md).
   * `Que.mode = :sync` - In this mode, any jobs you queue will be run in the same thread, synchronously (that is, `MyJob.enqueue` runs the job and won't return until it's completed). This makes your application's behavior easier to test, so it's the default in the test environment.
 
 **If you're using ActiveRecord to dump your database's schema, [set your schema_format to :sql](http://guides.rubyonrails.org/migrations.html#types-of-schema-dumps) so that Que's table structure is managed correctly.** (You can use schema_format as :ruby if you want but keep in mind this is highly advised against, as some parts of Que will not work.)
@@ -112,6 +112,7 @@ To determine what happens when a job is queued, you can set Que's mode. There ar
   * [que-web](https://github.com/statianzo/que-web) is a Sinatra-based UI for inspecting your job queue.
   * [que-testing](https://github.com/statianzo/que-testing) allows making assertions on enqueued jobs.
   * [que-go](https://github.com/bgentry/que-go) is a port of Que for the Go programming language. It uses the same table structure, so that you can use the same job queue from Ruby and Go applications.
+  * [wisper-que](https://github.com/joevandyk/wisper-que) adds support for Que to [wisper](https://github.com/krisleech/wisper).
 
 If you have a project that uses or relates to Que, feel free to submit a PR adding it to the list!
 

data/bin/que

@@ -4,6 +4,8 @@ require 'optparse'
 require 'ostruct'
 require 'logger'
 
+$stdout.sync = true
+
 options = OpenStruct.new
 
 OptionParser.new do |opts|
@@ -26,7 +28,7 @@ OptionParser.new do |opts|
   end
 
   opts.on('-v', '--version', "Show Que version") do
-    $stdout.puts "Que version #{Version}"
+    $stdout.puts "Que version #{Que::Version}"
     exit 0
   end
 
@@ -57,7 +59,7 @@ end
 Que.logger ||= Logger.new(STDOUT)
 
 begin
-  if log_level = options.log_level
+  if log_level = (options.log_level || ENV['QUE_LOG_LEVEL'])
     Que.logger.level = Logger.const_get(log_level.upcase)
   end
 rescue NameError
@@ -65,9 +67,9 @@ rescue NameError
   exit 1
 end
 
-Que.queue_name    = options.queue_name    || Que.queue_name    || nil
-Que.worker_count  = options.worker_count  || Que.worker_count  || 4
-Que.wake_interval = options.wake_interval || Que.wake_interval || 0.1
+Que.queue_name    = options.queue_name     || ENV['QUE_QUEUE']         || Que.queue_name    || nil
+Que.worker_count  = (options.worker_count  || ENV['QUE_WORKER_COUNT']  || Que.worker_count  || 4).to_i
+Que.wake_interval = (options.wake_interval || ENV['QUE_WAKE_INTERVAL'] || Que.wake_interval || 0.1).to_f
 Que.mode          = :async
 
 stop = false

data/docs/advanced_setup.md

@@ -1,5 +1,7 @@
 ## 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:
@@ -59,6 +61,9 @@ if defined?(PhusionPassenger)
 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:

data/docs/logging.md

@@ -1,6 +1,6 @@
 ## Logging
 
-By default, Que logs important information in JSON to either Rails' logger (when running in a Rails web process) or STDOUT (when running as a rake task). So, your logs will look something like:
+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"}}

data/docs/managing_workers.md

@@ -2,7 +2,7 @@
 
 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 (as it is by default when running `rails server`, or 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.
+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.
 
@@ -14,23 +14,19 @@ You can change the number of workers in the pool whenever you like by setting th
 Que.worker_count = 8
 ```
 
-### Working Jobs Via Rake Task
+### 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:
-rake que:work
+que
 
 # Or configure the number of workers:
-QUE_WORKER_COUNT=8 rake que:work
+que --worker-count 8
 ```
 
-Other options available via environment variables are `QUE_QUEUE` to determine which named queue jobs are pulled from, and `QUE_WAKE_INTERVAL` to determine how long workers will wait to poll again when there are no jobs available. For example, to run 2 workers that run jobs from the "other_queue" queue and wait a half-second between polls, you could do:
-
-```shell
-QUE_QUEUE=other_queue QUE_WORKER_COUNT=2 QUE_WAKE_INTERVAL=0.5 rake que:work
-```
+See `que -h` for a list of command-line options.
 
 ### Thread-Unsafe Application Code
 
@@ -40,10 +36,10 @@ If your application code is not thread-safe, you won't want any workers to be pr
 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 rake task, like so:
+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 rake que:work
+que --worker-count 1
 ```
 
 ### The Wake Interval
@@ -81,4 +77,4 @@ Que.wake_all!
 
 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 in a rake task, 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).
+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/multiple_queues.md

@@ -3,7 +3,7 @@
 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=credit_cards rake que:work
+que --queue-name credit_cards
 ```
 
 Then you can set jobs to be enqueued in that queue specifically:

data/docs/using_plain_connections.md

@@ -1,21 +1,6 @@
 ## Using Plain Postgres Connections
 
-If you're not using an ORM like ActiveRecord or Sequel, you can have Que access jobs using a plain Postgres connection:
-
-```ruby
-require 'uri'
-require 'pg'
-
-uri = URI.parse(ENV['DATABASE_URL'])
-
-Que.connection = PG::Connection.open :host     => uri.host,
-                                     :user     => uri.user,
-                                     :password => uri.password,
-                                     :port     => uri.port || 5432,
-                                     :dbname   => uri.path[1..-1]
-```
-
-If you want to be able to use multithreading to run multiple jobs simultaneously in the same process, though, you'll need the ConnectionPool gem (be sure to add `gem 'connection_pool'` to your Gemfile):
+If you're not using an ORM like ActiveRecord or Sequel, you can use one of two gems to manage a connection pool for your PG connections. The first is the ConnectionPool gem (be sure to add `gem 'connection_pool'` to your Gemfile):
 
 ```ruby
 require 'uri'
@@ -53,4 +38,4 @@ Que.connection = Pond.new :maximum_size => 10 do
 end
 ```
 
-Please be aware that if you're using ActiveRecord or Sequel to manage your data, there's no reason for you to be using any of these methods - it's less efficient (unnecessary connections will waste memory on your database server) and you lose the reliability benefits of wrapping jobs in the same transactions as the rest of your data.
+Please be aware that if you're using ActiveRecord or Sequel to manage your data, there's no reason for you to be using any of these methods - it's less efficient (unnecessary connections will waste memory on your database server) and you lose the reliability benefits of wrapping jobs in the same transactions as the rest of your data. In general, your app should probably be using a connection pool, and Que should probably hook into whatever connection pool you're already using.

data/lib/generators/que/install_generator.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'rails/generators'
 require 'rails/generators/migration'
 require 'active_record'

data/lib/generators/que/templates/add_que.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 class AddQue < ActiveRecord::Migration
   def self.up
     # The current version as of this migration's creation.

data/lib/que.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'socket' # For hostname
 
 module Que

data/lib/que/adapters/active_record.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   module Adapters
     class ActiveRecord < Base

data/lib/que/adapters/base.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'time' # For Time.parse.
 
 module Que

data/lib/que/adapters/connection_pool.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   module Adapters
     class ConnectionPool < Base

data/lib/que/adapters/pg.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'monitor'
 
 module Que

data/lib/que/adapters/pond.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   module Adapters
     class Pond < Base

data/lib/que/adapters/sequel.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   module Adapters
     class Sequel < Base

data/lib/que/job.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   class Job
     attr_reader :attrs

data/lib/que/migrations.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   module Migrations
     # In order to ship a schema change, add the relevant up and down sql files

data/lib/que/railtie.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   class Railtie < Rails::Railtie
     config.que = Que

data/lib/que/rake_tasks.rb

@@ -1,6 +1,10 @@
+# frozen_string_literal: true
+
 namespace :que do
   desc "Process Que's jobs using a worker pool"
   task :work => :environment do
+    $stdout.sync = true
+
     $stdout.puts "The que:work rake task has been deprecated and will be removed in Que 1.0. Please transition to the que command line interface instead."
 
     if defined?(::Rails) && Rails.respond_to?(:application)

data/lib/que/sql.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
   SQL = {
     # Locks a job using a Postgres recursive CTE [1].

data/lib/que/version.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 module Que
-  Version = '0.11.2'
+  Version = '0.11.3'
 end

data/lib/que/worker.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'monitor'
 
 module Que

data/spec/adapters/active_record_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 # Don't run these specs in JRuby until jruby-pg is compatible with ActiveRecord.
 unless defined?(RUBY_ENGINE) && RUBY_ENGINE == 'jruby'
 

data/spec/adapters/connection_pool_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 require 'connection_pool'
 

data/spec/adapters/pg_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe "Que using a bare PG connection" do

data/spec/adapters/pond_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 require 'pond'
 

data/spec/adapters/sequel_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 Que.connection = SEQUEL_ADAPTER_DB = Sequel.connect(QUE_URL)

data/spec/spec_helper.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'que'
 require 'uri'
 require 'pg'

data/spec/support/helpers.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 # Helper for testing threaded code.
 QUE_TEST_TIMEOUT ||= 2
 def sleep_until(timeout = QUE_TEST_TIMEOUT)

data/spec/support/jobs.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 # Common Job classes for use in specs.
 
 # Handy for blocking in the middle of processing a job.

data/spec/support/shared_examples/adapter.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 shared_examples "a Que adapter" do
   it "should be able to execute arbitrary SQL and return indifferent hashes" do
     result = Que.execute("SELECT 1 AS one")

data/spec/support/shared_examples/multi_threaded_adapter.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 shared_examples "a multi-threaded Que adapter" do
   it_behaves_like "a Que adapter"
 

data/spec/travis.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 #!/usr/bin/env ruby
 
 # Run tests a bunch of times, flush out thread race conditions /  errors.

data/spec/unit/connection_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que do

data/spec/unit/customization_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 # A few specs to ensure that the ideas given in the customizing_que document

data/spec/unit/enqueue_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que::Job, '.enqueue' do

data/spec/unit/helper_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que, 'helpers' do

data/spec/unit/logging_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe "Logging" do

data/spec/unit/migrations_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que::Migrations do

data/spec/unit/pool_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe "Managing the Worker pool" do

data/spec/unit/run_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que::Job, '.run' do

data/spec/unit/states_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que, '.worker_states' do

data/spec/unit/stats_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que, '.job_stats' do

data/spec/unit/transaction_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que, '.transaction' do

data/spec/unit/work_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que::Job, '.work' do

data/spec/unit/worker_spec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Que::Worker do

data/tasks/benchmark.rb

@@ -1 +1,3 @@
+# frozen_string_literal: true
+
 # The benchmarking tasks have been merged together and now live at github.com/chanks/queue-shootout.

data/tasks/rspec.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 require 'rspec/core/rake_task'
 
 RSpec::Core::RakeTask.new :default do |spec|

data/tasks/safe_shutdown.rb

@@ -1,3 +1,5 @@
+# frozen_string_literal: true
+
 # This task is used to test Que's behavior when its process is shut down.
 
 # The situation we're trying to avoid occurs when the process dies while a job

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: que
 version: !ruby/object:Gem::Version
-  version: 0.11.2
+  version: 0.11.3
 platform: ruby
 authors:
 - Chris Hanks
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-09-09 00:00:00.000000000 Z
+date: 2016-02-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler
@@ -125,7 +125,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.4.8
+rubygems_version: 2.5.1
 signing_key: 
 specification_version: 4
 summary: A PostgreSQL-based Job Queue