When running in distributed container environments (Kubernetes) resolving connection to statsd service may not always be successful, due to various reasons (outdated or lagging iptables is one of many). The current implementation does not provide good handling for such edge-case. While consumer of the client library can "re-dial" the socket connection, it has no control over metrics functionality (bar overloading send methods)
It would be very helpful if client library could "handle" this edge-case periodically retry socket connection while dropping current metrics.
Use-case:
Client attempts to open socket and receives dial TCP/UDP error
Client has the option to log error and continue
On every send invocation, client will attempt to reconnect if connection is nil
Expected outcomes:
A. socket creation is successful upon initial socket creation (current model)
B. socket creation failed upon initial attempt, however, subsequently succeeds. Impact: loss of metrics until the socket is re-dialled.
C. socket creation failed upon initial and on all successive attempts. Impact: loss of all metrics.
When running in distributed container environments (Kubernetes) resolving connection to
statsdservice may not always be successful, due to various reasons (outdated or laggingiptablesis one of many). The current implementation does not provide good handling for such edge-case. While consumer of the client library can "re-dial" the socket connection, it has no control over metrics functionality (bar overloadingsendmethods) It would be very helpful if client library could "handle" this edge-case periodically retry socket connection while dropping current metrics.Use-case:
dial TCP/UDPerrornilExpected outcomes:
A. socket creation is successful upon initial socket creation (current model) B. socket creation failed upon initial attempt, however, subsequently succeeds. Impact: loss of metrics until the socket is re-dialled. C. socket creation failed upon initial and on all successive attempts. Impact: loss of all metrics.