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.



19
20
21
22
23
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 19

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

Instance Method Details

#add(proc) ⇒ Object



25
26
27
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 25

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.



49
50
51
52
53
54
55
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 49

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

#runObject



57
58
59
60
61
# File 'lib/inst_jobs_statsd/stats/periodic.rb', line 57

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