Closed JensRantil closed 11 years ago
It reconnects at each flush interval (10s by default, but at bitly we use a 60s flush interval). The code could certainly be improved in this area. The current implementation doesn't handle write errors well (it drops data in that case) but does handle connect errors well (since they happen before building up a buffer of data to send). Switching to use a persistent connection would probably require a little bit of refactoring.
All that said, I haven't noticed any performance issues from the connect rate to carbon cache/relay so this hasn't been a focus.
Okay! Good to know! Thanks for quick response.
Just curious, is there a reason for statsdaemon reconnecting to graphite every ten seconds? Why not persist the connection instead (and try to reconnect if not connected)?