Goroutine fuite dans aws-sdk-go?

Question

J'ai le code de code suivant en utilisant la version actuelle aws-sdk-go v1.7.9.

sess, _ := session.NewSession() 
s3client := s3.New(sess) 
location, err := s3client.GetBucketLocation(&s3.GetBucketLocationInput{Bucket: &bucket}) 

Je consigner l'appel avant et après l'appel à GetBucketLocation(). Je vois le nombre total de goroutines augmenter de deux, avec ces deux goroutines supplémentaires en cours d'exécution après:

goroutine 45 [IO wait]: 
net.runtime_pollWait(0x2029008, 0x72, 0x8) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/runtime/netpoll.go:160 +0x59 
net.(*pollDesc).wait(0xc420262610, 0x72, 0xc42003e6f0, 0xc4200121b0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/fd_poll_runtime.go:73 +0x38 
net.(*pollDesc).waitRead(0xc420262610, 0xbcb200, 0xc4200121b0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/fd_poll_runtime.go:78 +0x34 
net.(*netFD).Read(0xc4202625b0, 0xc42022fc00, 0x400, 0x400, 0x0, 0xbcb200, 0xc4200121b0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/fd_unix.go:243 +0x1a1 
net.(*conn).Read(0xc42023c068, 0xc42022fc00, 0x400, 0x400, 0x0, 0x0, 0x0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/net.go:173 +0x70 
crypto/tls.(*block).readFromUntil(0xc42017c060, 0x2029248, 0xc42023c068, 0x5, 0xc42023c068, 0xc400000000) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/crypto/tls/conn.go:476 +0x91 
crypto/tls.(*Conn).readRecord(0xc42029a000, 0x840917, 0xc42029a108, 0xc420116ea0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/crypto/tls/conn.go:578 +0xc4 
crypto/tls.(*Conn).Read(0xc42029a000, 0xc420196000, 0x1000, 0x1000, 0x0, 0x0, 0x0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/crypto/tls/conn.go:1113 +0x116 
net/http.(*persistConn).Read(0xc42000ba00, 0xc420196000, 0x1000, 0x1000, 0x23d3b0, 0xc42003eb58, 0x7a8d) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/http/transport.go:1261 +0x154 
bufio.(*Reader).fill(0xc42000cba0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/bufio/bufio.go:97 +0x10c 
bufio.(*Reader).Peek(0xc42000cba0, 0x1, 0xc42003ebbd, 0x1, 0x0, 0xc42000cc00, 0x0) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/bufio/bufio.go:129 +0x62 
net/http.(*persistConn).readLoop(0xc42000ba00) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/http/transport.go:1418 +0x1a1 
created by net/http.(*Transport).dialConn 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/http/transport.go:1062 +0x4e9 

goroutine 46 [select]: 
net/http.(*persistConn).writeLoop(0xc42000ba00) 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/http/transport.go:1646 +0x3bd 
created by net/http.(*Transport).dialConn 
     /usr/local/Cellar/go/1.7.4_2/libexec/src/net/http/transport.go:1063 +0x50e 

Ces routines ne disparaissent pas au fil du temps et ils continuent d'accumuler plus d'appels sont faits à GetBucketLocation(). Est-ce que je fais quelque chose de mal (en négligeant de fermer une ressource) ou une fuite de goroutine se produit-elle dans aws-sdk-go?

Notez que le même comportement est observé avec la fonction s3manager.Downloader::Download().

Answer 1

Il s'est avéré que j'avais tort de dire que les routines ne disparaissent pas avec le temps. Si j'ajoute un sommeil de 10 secondes après l'appel à GetBucketLocation, avant d'imprimer la pile des goroutines, alors les routines supplémentaires disparaissent effectivement. Je crois que la raison en est que le paquet net/http de golang maintient un type de pool de connexions qui peut être réutilisé. Voir la discussion suivante: https://groups.google.com/forum/#!topic/golang-nuts/QckzdZmzlk0

En attente assez longtemps semble éventuellement fermer les connexions et arrêter les goroutines.