From a0c4bcf65176873b7af0895e229fe93c6bc71438 Mon Sep 17 00:00:00 2001 From: Phil Nash Date: Thu, 18 Aug 2016 22:52:58 +0100 Subject: [ci skip] Updates ActiveJob guide on default runner. The immediate runner is no longer default, the async adapter is. --- guides/source/active_job_basics.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'guides/source/active_job_basics.md') diff --git a/guides/source/active_job_basics.md b/guides/source/active_job_basics.md index c9f70dc87b..c65d1e6de5 100644 --- a/guides/source/active_job_basics.md +++ b/guides/source/active_job_basics.md @@ -34,8 +34,9 @@ Delayed Job and Resque. Picking your queuing backend becomes more of an operatio concern, then. And you'll be able to switch between them without having to rewrite your jobs. -NOTE: Rails by default comes with an "immediate runner" queuing implementation. -That means that each job that has been enqueued will run immediately. +NOTE: Rails by default comes with an asynchronous queuing implementation that +runs jobs with an in-process thread pool. Jobs will run asynchronously, but any +jobs in the queue will be dropped upon restart. Creating a Job @@ -109,7 +110,7 @@ That's it! Job Execution ------------- -For enqueuing and executing jobs in production you need to set up a queuing backend, +For enqueuing and executing jobs in production you need to set up a queuing backend, that is to say you need to decide for a 3rd-party queuing library that Rails should use. Rails itself only provides an in-process queuing system, which only keeps the jobs in RAM. If the process crashes or the machine is reset, then all outstanding jobs are lost with the -- cgit v1.2.3