You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some processors in libbeat have resources that need to be released when they're done. These processors implement the interface Closer in addition to the baseline Processor. However, it looks like the Close function is never getting called on such processors. This probably affects all Beats versions for at least the last ~2 years.
Here is the function that closes a processor, in libbeat/processors/processor.go:
// Close closes a processor if it implements the Closer interfacefuncClose(pProcessor) error {
ifcloser, ok:=p.(Closer); ok {
returncloser.Close()
}
returnnil
}
However, both Processor and Closer are interface types:
and interface casts like that only work if one interface is a refinement of the other, they do not check the underlying type. See for example this demonstration of the issue in a go playground. This probably means that the underlying struct for all closable processors is never receiving a Close call.
This is related to but independent from the recent error loops in #34716.
The text was updated successfully, but these errors were encountered:
Some processors in libbeat have resources that need to be released when they're done. These processors implement the interface
Closer
in addition to the baselineProcessor
. However, it looks like theClose
function is never getting called on such processors. This probably affects all Beats versions for at least the last ~2 years.Here is the function that closes a processor, in
libbeat/processors/processor.go
:However, both
Processor
andCloser
are interface types:and interface casts like that only work if one interface is a refinement of the other, they do not check the underlying type. See for example this demonstration of the issue in a go playground. This probably means that the underlying struct for all closable processors is never receiving a
Close
call.This is related to but independent from the recent error loops in #34716.
The text was updated successfully, but these errors were encountered: