RSpec でキューイングした ActiveJob を同期実行する - Qiita
ジョブの実行をテストしたいとき、キューに入ったことをテストしたいだけのときと、その実行結果まで含めてテストしたいとき（つまり同期実行したいとき）がある。 前者であればRails.application.config.active_job.queue_adapter = :testで足りるが、後者を実現するためにはどうすればよいだろう。 方法はいくつかあって、まずはRails.application.config.active_job.queue_adapter = :inlineとする方法。 これは簡単に同期実行は実現できるが、こんどはキューに入ったことが確認できなくなってしまうし、他の非同期のままにしておきたいところまで影響がでてしまう。 またSidekiqを使っているのであればSidekiq::Testing.inline!やSidekiq::Testing.fake! で制御すること
ActiveJobでリトライ制御 - Qiita
ActiveJob はまだまだリトライ制御機能が弱く、retry_job での単純な再実行位しか機能がありません1。 そこで、公式ドキュメントで公開されている API のみを活用し、ある程度の制御が行えるモジュールを作成しました。 成功するまでリトライ まず retry_job を使ったシンプルな例です。 StandardError が発生すると、rescue_fromで補足され、5分後に再実行するようにスケジューリングされます。 ただし、これでは成功するまで無限にリトライが行われてしまいます。リトライ回数の制限を行おうと思っても、現状 ActiveJob ではその制御機構がありません。 当然 Gems もいくつか既に提供されていますが、まだまだ「これが間違いない」と思える gem が出てきてないように思います。 おそらく一番 Github でスターが多いのが ActiveJob::Ret
Railsで非同期処理：キュー。Sidekiq（+ActiveJob）がResqueよりも、とても簡単便利。 - Qiita
メール送信や、重い処理、バッチなどでキューイングってよくやると思うんですが、Rubyではそれらを簡単に実現できるライブラリがいくつかあります。有名所だと、Sidekiq / Resque / Delayed Jobとか。僕はSidekiq / Resqueこの2つを使ったことがあるんですが…最近ではSidekiqの方が設定も簡単で使いやすかったので、Sidekiqにまつわる設定などもろもろまとめておきます。 ActiveJobについて Rails4.2からActiveJobというキュー操作のフレームワークが導入されました。これを使用することで、書き方が統一されるため、バックグラウンドのキューライブラリがSidekiqだろうとResqueだろうと気にせず書けるっていうやつです。Rails4.2を使っているのなら積極的に採用して良い感じ。 (2017/08/07：追記） 実際にいくつかのプロジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
