square
"start" and "stop" event for cubism.context
These events are useful for sources which needs synchronization e.g. for starting/stopping and internal scheduler for pulling periodically data (like Jolokia does).
I’m not sure it’s sufficiently useful (meaning: essential) to add to the API. If it’s your code that’s calling context.start and context.stop, you can coordinate that method call with other operations that your code depends on.
It seems a little funny to add this responsibility to the context, when in general, classes aren’t responsible for reporting events when you call methods on them. On the other hand, since the context already broadcasts events for its state, I suppose you could argue that whether the context is running or not is reasonable to add to the API.
If your metric wants to prefetch data on a regular schedule, rather than pulling data on demand as the metric API is intended, you can use the existing metric API to control your scheduled pulls implicitly through timeouts. All you have to do is pause the periodic pulls if your metric’s request function hasn’t been called in a while.
Maybe explaining my use case clarifies a bit, why I want to hook into the context's lifecycle.
I uses cubism for graphing live data obtained from Jolokia which is a JMX-HTTP bridge. Therefore I implemented an new data source which periodically fetches this live data and stores it in an array. You can see it in action on this demo page, the documentation can be found here.
My point is, that I need a second scheduler for live measuring the data on a regular basis (with fixed ticks), independent from the cubism scheduler. So, it is not about prefetching data from a backend store, which already has a timeseries for the charting data available.
So I think it is a good idea would be to couple the lifecycles of both schedulers, where this pull request provides an easy way for.
Of course the alternative is to manage both lifecycles externally:
var context = cubism.context();
var jolokia = context.jolokia("http://jolokia.org/jolokia");
// Create some metrics ....
jolokia.start();
context.start();
This is the way how it is done now, with this patch one could save the jolokia.start() call. This would be nice also from an API perspective in order to hide implementation details of this data source.