和訳：sidekiq-shceduler README - Qiita
2016-12-10T11:53:08.561Z 6452 TID-ovouhwvm4 INFO: Loading Schedule 2016-12-10T11:53:08.561Z 6452 TID-ovouhwvm4 INFO: Scheduling HelloWorld {"cron"=>"0 * * * * *", "class"=>"HelloWorld"} 2016-12-10T11:53:08.562Z 6452 TID-ovouhwvm4 INFO: Schedules Loaded 2016-12-10T11:54:00.212Z 6452 TID-ovoulivew HelloWorld JID-b35f36a562733fcc5e58444d INFO: start Hello world 2016-12-10T11:54:00.213Z 6452 TID-ovoul
Sidekiq で最大回数リトライ後に失敗した場合出すログに例外のバックトレースを含める - Qiita
この記事では Sidekiq 5 系を対象にしていますが、4 系でも変わらない内容です。 Sidekiq Worker を利用する利点の一つに、 リトライ処理 を Sidekiq に任せられる点があります。 リトライを安全に実行するために、Sidekiq Worker の処理を冪等にしておくことは Sidekiq の Best Practice にも触れられています。以下は引用です。 2. Make your job idempotent and transactional Idempotency means that your job can safely execute multiple times. For instance, with the error retry functionality, your job might be half-processed, throw an
Sidekiqで非業の死を遂げたキューを知る方法 - Qiita
前置き：Rubyのキューイングシステム Rails（Ruby）で非同期にキューイングしてくれるライブラリといえばSidekiqですよねっていうくらいSidekiqが好きなんですが、世の中のシェア的にはResqueなのかな。でも、Sidekiqの方が安定的に動かせているので僕は好きです（delayed_jobは知らない）。 ShoryukenというAWS SQSを使ったキューイングシステムもあり、RedisじゃなくてSQS使いたいっていう場合は、これも良いのかもしれないですね。まぁ、ローカルの場合面倒そうな感じもありますけど。 phstc/shoryuken まぁともかくSidekiqを導入してキューイングするっていうのは、もう超絶簡単にできるわけです。できるんですけど、実際にラフに運用していくと、キューがいつの間にかこけて処理待ちで埋まってたり、レアなケースで例外投げて死んでたりするわけで
Sidekiq で queue に入った job を手動で削除する - Qiita
class SampleWorker include Sidekiq::Worker # 以下のように queue を default 以外を利用する場合は以下の説明もそれに読み替えてください。 # sidekiq_options queue: :sample_worker def perform(id) # id 使って DB からデータ読み出したりして処理する想定 end end # 削除したい id を Worker deletion_target_id = '12345678' worker = 'SampleWorker' queue = Sidekiq::Queue.new('default') # default 以外なら queue 名を指定 queue.each do |job| next unless job.klass == worker # job['class']
ElastiCache がフェイルオーバーした際に気をつけるべき redis-rb の利用方法について - Qiita
遭遇した状況 今回は中でも ElastiCache プライマリクラスターのみで障害が発生した場合 の話しです。 ドキュメントにもあるように、マルチAZ 環境での自動フェイルオーバーでの今回の状況においては 書き込みは、昇格プロセスが完了するとすぐに (通常は数分) 再開できます。ElastiCache が昇格したレプリカの DNS を反映させるため、書き込みのためのエンドポイントを変更する必要はありません。 となっています。 ポイントは、「DNS を反映させるため、書き込みのためのエンドポイントを変更する必要がありません」というところです。 発生した課題 自動フェイルオーバーが発生した際に、運用している Rails アプリから上記のエラーが止まらないと言う状況になりました。 最終的には、Web アプリ、ワーカーアプリともに、再起動することで状況は改善しました。 このエラーメッセージから分か
Elixirを使ってSidekiqを操作する - Qiita
はじめに これは 【その1】ドリコム Advent Calendar 2015 の19日目の記事です。 18日目はYさんの記事でした。 【その2】ドリコム Advent Calendar 2015の18日目はwasbi01さんの記事でした。 寺社自社で開発/運用している、Elixirを利用した広告配信システムについて紹介したいと思います。 自己紹介 @ohrdev 普段は写経(仏教的な意味で)や仏像彫り、寺社仏閣巡りをしています。 空いた時間はドリコムという会社で広告周りのシステムの開発をしています。 好きなbehaviourはgen_eventです。 Elixirについて ElixirはErlangのVM上で動作する比較的新しいプログラミング言語です。 Erlangで実装されている為、分散、耐障害性、ソフトリアルタイムといった(Erlangの)特徴を兼ね備え、Elixir独自の、マクロ、
Celluloidのはなし - Qiita
require 'celluloid' class Counter include Celluloid attr_reader :count def initialize @count = 0 end def increment(n = 1) sleep n @count += n end end actor = Counter.new p actor.count #=> 0 p actor.increment #=> 1 p actor.async.increment(41) #=> nil p actor.count #=> 1 Celluloidの機能を使うには、ActorにしたいクラスにCellloidをincludeします。 #asyncをはそれに続くメソッド呼び出しが非同期になるようなプロキシを返します。メソッド呼び出しはnilを返すため、本来返ってくるはずの返り値は使えません
Railsで非同期処理：キュー。Sidekiq（+ActiveJob）がResqueよりも、とても簡単便利。 - Qiita
Railsで非同期処理：キュー。Sidekiq（+ActiveJob）がResqueよりも、とても簡単便利。RubyRailsResquesidekiqActiveJob メール送信や、重い処理、バッチなどでキューイングってよくやると思うんですが、Rubyではそれらを簡単に実現できるライブラリがいくつかあります。有名所だと、Sidekiq / Resque / Delayed Jobとか。僕はSidekiq / Resqueこの2つを使ったことがあるんですが…最近ではSidekiqの方が設定も簡単で使いやすかったので、Sidekiqにまつわる設定などもろもろまとめておきます。 ActiveJobについて Rails4.2からActiveJobというキュー操作のフレームワークが導入されました。これを使用することで、書き方が統一されるため、バックグラウンドのキューライブラリがSidekiqだろ
herokuでsidekiq起動時のエラー対処方法 - Qiita
# config/sidekiq.yml :verbose: true :pidfile: ./tmp/pids/sidekiq.pid :logfile: ./log/sidekiq.log :concurrency: 2 :queues: - default # Procfile web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb worker: bundle exec sidekiq -C config/sidekiq.yml ProcfileでLaunchingのコマンドを足したので動くと思ってたんですがダメでした。 config/sidekiq.ymlが悪いのか、config/secrets.ymlでREDISTOGO_URLを受け取れてないのかいろいろ疑ったんですが、結局ログ見たらtmp/pidsディレクトリが無いと
Sidekiq 3.0にするとQueueがいつまで経っても実行されない - Qiita
最近定番となってるSidekiqですが、少し前にメジャーバージョンアップがありました。 いままで通りに設定して、workerを起動してもいつまで経ってもQueueが実行されないので調べたところ、どうやらinitializerにかいた設定をserver/clientの両方の記述する必要がありそうです。 Sidekiq.configure_server do |config| config.redis = { url: 'redis://localhost:6379', namespace: 'sidekiq' } end Sidekiq.configure_client do |config| config.redis = { url: 'redis://localhost:6379', namespace: 'sidekiq' } end
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
sidekiqの使い方 - Qiita