README.md in backburner-1.1.0 vs README.md in backburner-1.2.0.pre

- old
+ new

@@ -111,14 +111,16 @@ | ----------------- | ------------------------------- | | `beanstalk_url` | Address such as 'beanstalk://127.0.0.1' or an array of addresses. | | `tube_namespace` | Prefix used for all tubes related to this backburner queue. | | `namespace_separator` | Separator used for namespace and queue name | | `on_error` | Lambda invoked with the error whenever any job in the system fails. | -| `default_worker` | Worker class that will be used if no other worker is specified. | | `max_job_retries` | Integer defines how many times to retry a job before burying. | | `retry_delay` | Integer defines the base time to wait (in secs) between job retries. | | `retry_delay_proc` | Lambda calculates the delay used, allowing for exponential back-off. | +| `default_priority` | Integer The default priority of jobs | +| `respond_timeout` | Integer defines how long a job has to complete its task | +| `default_worker` | Worker class that will be used if no other worker is specified. | | `logger` | Logger recorded to when backburner wants to report info or errors. | | `primary_queue` | Primary queue used for a job when an alternate queue is not given. | | `priority_labels` | Hash of named priority definitions for your app. | | `reserve_timeout` | Duration to wait for work from a single server, or nil for forever. | @@ -156,11 +158,11 @@ 1000 # most urgent priority is 0 end # optional, defaults to respond_timeout def self.queue_respond_timeout - 300 # number of seconds before job times out, 0 to avoid timeout + 300 # number of seconds before job times out, 0 to avoid timeout. NB: A timeout of 1 second will likely lead to race conditions between Backburner and beanstalkd and should be avoided end end ``` You can include the optional `Backburner::Queue` module so you can easily specify queue settings for this job: @@ -236,28 +238,28 @@ User.async(:queue => lambda { |user_klass| ["queue1","queue2"].sample(1).first }).do_hard_work # would add the job to either queue1 or queue2 randomly ``` ### Using Async Asynchronously ### -It's often useful to be able to configure your app in production such that every invocation of a method is asynchronous by default as seen in [delayed_job](https://github.com/collectiveidea/delayed_job#queuing-jobs). To accomplish this, the `Backburner::Performable` module exposes two `handle_asynchronously` convenience methods +It's often useful to be able to configure your app in production such that every invocation of a method is asynchronous by default as seen in [delayed_job](https://github.com/collectiveidea/delayed_job#queuing-jobs). To accomplish this, the `Backburner::Performable` module exposes two `handle_asynchronously` convenience methods which accept the same options as the `async` method: ```ruby class User include Backburner::Performable def send_welcome_email # ... end - + # ---> For instance methods handle_asynchronously :send_welcome_email, queue: 'send-mail', pri: 5000, ttr: 60 def self.update_recent_visitors # ... end - + # ---> For class methods handle_static_asynchronously :update_recent_visitors, queue: 'long-tasks', ttr: 300 end ``` @@ -469,10 +471,10 @@ ``` Note the default `max_job_retries` is 0, meaning that by default **jobs are not retried**. As jobs are retried, a progressively-increasing delay is added to give time for transient -problems to resolve themselves. This may be configured using `retry_delay_proc`. It expects +problems to resolve themselves. This may be configured using `retry_delay_proc`. It expects an object that responds to `#call` and receives the value of `retry_delay` and the number of times the job has been retried already. The default is a cubic back-off, eg: ```ruby Backburner.configure do |config|