The brief idea here is that we would like more explicit control over how and when to send a batch of stats to the statsd process. This PR adds one more control, specifically the time interval at which stats batches are sent. This API change is not breaking in terms of a major version as the default functionality is maintained but a new parameter is added to the configuration which allows this finer grained control. In addition to this finer control we also allow manual flushing (ie on-demand flushing of batches of stats in the queue). This allows a calling application to queue/batch stats as much as they want and then decide on thier own when is a good time to send those to statsd.
I've updated the documentation in the code to spell this out but this could probably also be done in the README, ~so I'll add that too~ I've added that.
~I'll put this in draft for now as I didnt write the unit tests yet. Once I have the tests and the README updated I'll take it out of draft~ this has all been done.
@vthiery let me know what your opinion is on this extra level of control. I also thought maybe I should add an accessor to return the queue depth as it might inform the callers decision about when to flush the stats if they are doing it manually.
fixes #20
The brief idea here is that we would like more explicit control over how and when to send a batch of stats to the statsd process. This PR adds one more control, specifically the time interval at which stats batches are sent. This API change is not breaking in terms of a major version as the default functionality is maintained but a new parameter is added to the configuration which allows this finer grained control. In addition to this finer control we also allow manual flushing (ie on-demand flushing of batches of stats in the queue). This allows a calling application to queue/batch stats as much as they want and then decide on thier own when is a good time to send those to statsd.
I've updated the documentation in the code to spell this out but this could probably also be done in the README, ~so I'll add that too~ I've added that.
~I'll put this in draft for now as I didnt write the unit tests yet. Once I have the tests and the README updated I'll take it out of draft~ this has all been done.
@vthiery let me know what your opinion is on this extra level of control. I also thought maybe I should add an accessor to return the queue depth as it might inform the callers decision about when to flush the stats if they are doing it manually.