Class: InstJobsStatsd::Stats::Periodic::Callbacks

Inherits:
Object
  • Object
show all
Defined in:
lib/inst_jobs_statsd/stats/periodic.rb

Instance Method Summary collapse

Constructor Details

#initialize(min_interval = 60) ⇒ Callbacks

Returns a new instance of Callbacks.



34
35
36
37
38
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 34

def initialize(min_interval = 60)
  @timer = Timer.new(min_interval)
  @procs = []
  register_lifecycle
end

Instance Method Details

#add(proc) ⇒ Object



40
41
42
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 40

def add(proc)
  @procs << proc if proc
end

#register_lifecycleObject

This hooks into the lifecycle events such that it will get triggered periodically which reasonable certainty – as long as the rest of the inst-jobs processing system is working, any way. This allows for stats to be reported periodically without having to start a separate sideband process. It means that reporting of those stats will run inline (in the same process and thread) as the regular job processing work, but it also means no need for an additional database connection, and no managing of additional threads or processes.

The :work_queue_pop event is used becaused in production mode, the ‘parent_process’ work queue is typically going to be used, and this callback runs in the parent process – as opposed to having this callback run in each of the subordinate worker processes, which would not be ideal. In a dev env with the ‘in_process’ work queue, there’s typically only going to be a single worker process anyway, so it works just as well.



64
65
66
67
68
69
70
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 64

def register_lifecycle
  Delayed::Worker.lifecycle.after(:work_queue_pop) do |_q, _c|
    @timer.tick do
      run
    end
  end
end

#runObject



72
73
74
75
76
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 72

def run
  InstStatsd::Statsd.batch do
    @procs.each(&:call)
  end
end