You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand the need (keep this entirely non-blocking), but was wondering what would be the right approach for this to be added (willing to file a PR, but want to make sure it can be merged before I go ahead).
Just spitballing, since I'm just a dude, not a DataDog dude, but I wonder if a reasonable strategy here would be to extract the behavior of sending socket messages out into its own object. Sending data over UDP is a different responsibility from serializing UDP message strings so they conform to dogstatsd (which is what most of DogStatsd is about), and if a user could supply their own "sender" object, the specific send implementation could be made entirely flexible.
An interface called \DataDog\DogStatsd\Sender that supported a single public method send would be nice. Then you could extract the curl send logic and the UDP over IP send logic into their own Sender implementations.
I had to stub global socket functions at the namespace level to test that the global socket_* functions were being called correctly, which is boilerplate I could avoid if I could instead pass DogStatsd a mock of a Sender implementation.
Currently, the code does not resolve domain names for UDP transport:
php-datadogstatsd/src/DogStatsd.php
Lines 295 to 302 in def70c3
I understand the need (keep this entirely non-blocking), but was wondering what would be the right approach for this to be added (willing to file a PR, but want to make sure it can be merged before I go ahead).
/cc @jitendra-1217
The text was updated successfully, but these errors were encountered: