leak with 3.6.4 and datadog.api.ServiceCheck.check

[thehesiod]

with a script like the following:

from datadog import initialize as dd_init, api as dd_api
from datadog.api.constants import CheckStatus as dd_CheckStatus
import logging

HOST_NAME = 'XXXX'

def test():
    response = dd_api.ServiceCheck.check(**{'check': 'execution_state', 'host_name': HOST_NAME, 'status': 0})
    assert response['status'] == 'ok', "Response failed: {}".format(response)

def main():
    logging.basicConfig(level=logging.INFO)
    logger = logging.getLogger()

    dd_init(DATADOG_KEY, host_name=HOST_NAME)

    while True:
        test()


if __name__ == '__main__':
    main()

memory usage will continue creeping up. Using tracemalloc you'll find memory will be attributed to a stack like the following:

      File "/Users/amohr/.pyenv/versions/3.6.4/lib/python3.6/site-packages/datadog/api/resources.py", line 370
        return APIClient.submit(method, name, body)
      File "/Users/amohr/.pyenv/versions/3.6.4/lib/python3.6/site-packages/datadog/api/service_checks.py", line 42
        return super(ServiceCheck, cls)._trigger_action('POST', 'check_run', **body)
      File "/Users/amohr/Library/Preferences/PyCharm2017.3/scratches/re_leak.py", line 15
        response = dd_api.ServiceCheck.check(**{'check': 'CalendarSyncer.execution_state', 'host_name': HOST_NAME, 'status': 0})
      File "/Users/amohr/Library/Preferences/PyCharm2017.3/scratches/re_leak.py", line 30
        test()
      File "/Users/amohr/Library/Preferences/PyCharm2017.3/scratches/re_leak.py", line 36
        main()

I traced it to: datadog.api.http_client:RequestClient.request missing a s.close(). It appears if you don't close a requests session it will not go away :(

[thehesiod]

btw, this is pretty heavy handed of creating a session for each request given a session creates a pool of connections. It would be nice to know why this seems to leak w/o calling close. The closest conversation I found to this was: psf/requests#1685 . Also perhaps this session was created to make it thread safe? would be worth a comment. Still getting a leak with the above PR too :(

[thehesiod]

closing as I've found that tracemalloc seems to be giving garbage results when used with lots of threads :(