aristanetworks / aristanetworks/goeapi
Possible connection leak?
- Dominant language
- Go
- Stars
- 60
- Forks
- 36
- PR merge metrics
- No merged PRs in 30d
Description
I'm seeing issues where connections are not cleaned up after a request is issued. In a case I'm working on, a connection to several hundred devices exhausts my local open file handle limit and causes the program to stop functioning.
`while true; do lsof -i -n -P | grep main | awk '{ print $9 }' |awk -F'>' '{print $2}' | sort | uniq -c | sort -n ; sleep 1; echo;done`
This yields something like the following:
```
5 192.168.10.17:443
5 192.168.10.24:443
5 192.168.10.30:443
5 192.168.10.36:443
5 192.168.10.38:443
5 192.168.10.40:443
5 192.168.10.48:443
5 192.168.10.50:443
5 192.168.10.54:443
```
This indicates that there are 5 connections to each host I'm connected to, which I believe is the result of the HTTPs connection pooling provided by http.Client. Though the decode of the JSON doesn't appear to perform the ReadAll necessary to clean up the client connections to the given host. Note also that for a given run, each `send()` call creates a new client, which I believe further exacerbates the issue in my conditions here. It's late on a Friday and I'm heading into the weekend, but wanted to make a note.
Contributor guide
Research direction
Start by tracing the send() call and how its http.Client is created for each request. Inspect the JSON decode path and response-body handling, then reproduce repeated requests against multiple hosts while monitoring open connections; done means connections no longer accumulate until the file-handle limit is exhausted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100