Exceptions caused by synchronous putEntities requests can be swallowed

TimelineCollector.putEntitities() is currently implemented by calling TimelineWriter.write() followed by TimelineWriter.flush(). Given HBaseTimelineWriter.write() is an asynchronous operation, it is possible that TimelineClient sends a synchronous putEntities() request for critical data, but never gets back an exception even though the HBase write request to store the entities may have failed.

This is due to a race condition between the WriterFlushThread in TimelineCollectorManager and web threads handling synchronous putEntities() requests. Entities are first put into the buffer by the web thread, it is possible that before the web thread invokes writer.flush(), WriterFlushThread is fired up to flush the writer. If the entities were not successfully written to the backend during flush, the WriterFlushThread would just simply log an error, whereas the web thread would never get an exception out from its writer.flush() invocation. This is bad because the reason of TimelineClient sending synchronously putEntities() is to retry upon any exception.