Update lib/carbon/aggregator/buffers.py

Closing MetricBuffers after all interval buffers are outside the age threshold.
carbon.conf: Add [aggregator] WRITE_BACK_FREQUENCY
Merge pull request #50 from jdanbrown/write-back-frequency

carbon.conf: Add [aggregator] WRITE_BACK_FREQUENCY
Fix relay's per-destination instrumentation
use global event handlers properly in client.py
added warning if the aggregator is misconfigured
caron(-aggregrator) will substitute a timestamp of 0 with the current time, to enable time synchronised stats
Clean up the code a bit in the example client
Remove a bit of unnecessary code
Add carbon.exceptions

For now, this only contains CarbonConfigException, but we can add
more later down the road depending on what types of failure conditions
we want to gracefully handle and report. I see a lot of ceres related
potential here.
Update carbon.conf and it's unit tests for the new exception

Also silence an annoying DeprecationWarning when running the tests
Update daemons to use new exceptions and gracefully print them
Updating test to not use deprecated e.message
Changed special timestamp '0' to '-1'
The length of the carbon-relay's per-destination queue is not visible.

This patch adds
carbon.relays.<hostname>.destinations.<dest-host>.relayMaxQueueLength,
a counter that records the maximum queue length for that destination
during the reporting period.
Remove an un-needed attempt to send a instrumentation stat.
Make sending stats more asynchronous and batched.

All stats are now put into the relay's CarbonClientFactory's queue.

The queue is now implemented using a collections.deque.  Prior to this
patch, multiple copies of the majority of the queue would be copied
after an stats built up, e.g. after an outage between a relay and one
of its destinations.  If that queue was large, multiple copies of the
vast majority of the list would be copied over and over again.  Lots
of potential for thrashing there.

Now, when a stat is enqueued a write is scheduled via
twisted.internet.reactor.callLater().  A configurable delay, which
defaults to .0001 seconds, is given to allow more stats to enter the
queue, and once that time is up, the queue will be cleared.

Now, when the queue is cleared, once MAX_DATAPOINTS_PER_MESSAGE is
retrieved from the queue and sent, the callLater method mentioned
above will be used again to schedule the next batch.  The delay for
this should be effectively zero (0.000001).

The reason that callLater is being used instead of a loop is to
release the lock on the event loop, allowing metrics to flow in
asynchronously.  This is an attempt to fix the same problem that
https://github.com/mleinart/carbon/commit/9ac8202b54ff4f82a6f7c51529b1d671bb1d56a5,
is trying to fix, but without introducing out-of-order stats.
Fix some relay-related stats not getting updated.
Updated the comments in carbon.conf based on my observations of how
the recent changes to the relay can affect a cluster.
Merge pull request #90 from pcn/add-relay-queue-stat

The length of the carbon-relay's per-destination queue is not visible.