reverseproxy, admin: memory leak fix

[dtelyukh]

See good explanation: https://www.arangodb.com/2020/09/a-story-of-a-memory-leak-in-go-how-to-properly-use-time-after/

[mholt]

Hey thanks for this. I will look at this after the holidays!

[vishal1132]

Do you think it might be a good idea to drain the timer in it's own goroutine if the timer.Stop() call doesn't stop the timer. For example something like-

go func(){
	<-timer.C
}()

Also the comment on top of it is not very useful I think. Also, thanks TIL about this memory leak.

[mholt]

I don't think so; see the docs: https://pkg.go.dev/time#Timer.Stop

[vishal1132]

@mholt If the timer has already expired and time.Stop() wouldn't return true and <-timer.C would ensure a value atleast after the duration, but it can be very long too. Draining this in a goroutine would ensure the normal flow of the code from this point of view and draining elsewhere. Please let me know if I am missing something and sorry for being noob in that case.

[mholt]

No, this only reads from the channel if the timer has already been stopped or expired. So the read will never be blocking in this case.

[mholt]

Thank you for this contribution -- I suppose I was just lazy, and perhaps this will save some users a little bit of trouble and keep our allocations tidy.