Change graphite connect logic to lookup dns names on reconnect

[goraxe]

We had various issues with dns names for our graphite host changing (its an aws ALB and the ip addresses rotate fairly frequently). I have tracked down the issue to the hostname not being re-resolved by InetSockAddress once it has an address. This code will now always attempt to re-resolve (with default java jvm ttl of 30s, or dns resolve cache ttl applying)

[arteam]

I think this change actually better, because it explicitly forces a DNS lookup every time GraphiteReporter reports metric. I will cut a new release with this change.

[arteam]

Thank you, @goraxe! I've released Metrics 4.1.1 and 4.0.7 which should contain the change.

[chengchen]

Hello @goraxe @arteam, I took a look at this commit and tried to use this constructor Graphite(InetSocketAddress address) to initialize Graphite. It seems that this fix is still not going to solve the issue, right?

Since the hostname would be null all the time, the address is always the old InetSocketAddress (not null), so address = new InetSocketAddress(InetAddress.getByName(hostname), port) will never be executed again.

[goraxe]

@chengchen yes, we actually hit the same issue and switched to using the constructor Graphite(String hostname, String port). With the InetSocketAddress path there is not an easy way to get at the original hostname (reverse dns may not point at the dns name for eg). I didn't want to mess with the api to deprecate the InetSocketAddress constructor as that might be valid uses cases for it (I'm just a drive by contributor so its not my call to make) there is the caveat that dns changes will not propagate (as that has been explictly done outside of the graphite code).

[chengchen]

@goraxe Thanks for the explanations. I noticed this inconsistency because we were using InetSocketAddress.createUnresolved(String host, int port) to work around this problem in the past. And your changes made it broken completely. Now, I look back into this code realizing that using Graphite(String hostname, String port) works just fine even without your changes. That's basically why I was asking. IMHO, this class requires some serious cleanup but of course, this is not a message for you.