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.



22
23
24
25
26
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 22

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

Instance Method Details

#add(proc) ⇒ Object



28
29
30
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 28

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.



52
53
54
55
56
57
58
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 52

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

#runObject



60
61
62
63
64
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 60

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