Sarama metrics leak in gracefull shutdown

[pandarun]

Description

add go-leak detector next to integration test

import "go.uber.org/goleak"

func TestMain(m *testing.M) {
	goleak.VerifyTestMain(m)
}

Versions

https://github.com/rcrowley/go-metrics/blob/cf1acfcdf4751e0554ffa765d03e479ec491cad6/meter.go#L239

Sarama	Kafka	Go
github.com/IBM/sarama v1.43.1		1.22.2

go.uber.org/goleak v1.3.0

Configuration

var arbiter = meterArbiter{ticker: time.NewTicker(5e9), meters: make(map[*StandardMeter]struct{})}

// Ticks meters on the scheduled interval
func (ma *meterArbiter) tick() {
  for {
    select {
    case <-ma.ticker.C:
      ma.tickMeters()
    }
  }
}

Logs

[Goroutine 621 in state chan receive, with github.com/rcrowley/go-metrics.(*meterArbiter).tick on top of the stack:
github.com/rcrowley/go-metrics.(*meterArbiter).tick(0x1e2dd40)
  /go/pkg/mod/github.com/rcrowley/go-metrics@v0.0.0-20201227073835-cf1acfcdf475/meter.go:239 +0x33
created by github.com/rcrowley/go-metrics.NewMeter in goroutine 633
  /go/pkg/mod/github.com/rcrowley/go-metrics@v0.0.0-20201227073835-cf1acfcdf475/meter.go:46 +0x18f
]

Additional Context

the issue can be workarounded by adding in integration tests package

metrics.UseNilMetrics = true

[puellanivis]

I’m confused about why you think this leak is in sarama.

The code referenced is a forever loop, and the referenced line meter.go:46 is go arbiter.tick().

The goroutine leak is patently in the other library, which spins off a goroutine with no consideration for when it should end.