How can a Plugin detect when its config is destroyed/cancled/no longer needed? about traefik HOT 5 CLOSED

But isn't Traefik somewhat responsible for the life cycle of the Plugin? Traefik instantiates the plugin, but there is no way of knowing if plugin instance is no longer needed e.g. if its configuration is removed. Like a method close() on the plugin that is called when the plugin is no longer needed, so that it can cleanup resources allocated (like the mentioned goroutine).

I just don't see how the plugin is suppose to know when it is no longer needed? But maybe there is already another mechanism for this in place?

from traefik.

Hi @simonpahl
There is not much Traefik can do with the problem you are mentionning, it must be handled by the plugin. Plugins are maintained by the community, therefore, I encourage you to reach out directly to the maintainers of the plugin.
I'm closing this issue, don't hesitate to open a new one if you find another bug :)
Thank you

from traefik.

I agree with @simonpahl it is very weird that the middleware API notifies you of new configurations but does not notify of updates/removals, which means it only covers half the life-cycle of middleware management and makes it easy to leak resources :-/

@simonpahl you can use runtime.SetFinalizer() as a workaround, it is a bit hackish but there's no other way around as far as I know.

from traefik.

I did experiments with runtime.SetFinalizer() on the config object, but it never seems to be called. I don't think i can register a finalizer on the plugin itself, because the goroutine would always have a reference of it and thus it would never be GCed.

from traefik.

You can definitely register a finalizer, that's what I had to do in a middleware I wrote to prevent a memory leak upon configuration reload, and I have a log in the finalizer so I know for sure it is being called.

One caveat though: the finalizer callback must be very careful not to reference (directly or indirectly) the object being finalized otherwise the object can´t be garbage collected...

[...]
z.member = f

runtime.SetFinalizer(f, func (o *Foo) {
    fmt.Println("ooopsy, now f is directly referenced so it never gets finalized ", f)
    fmt.Println("ooopsy, now z is indirectly referenced so it never gets finalized ", z)
})
[...]

I'll just point out that this is very hackish and that in the past there were discussions about runtime.SetFinalizer deprecation due to the lack of guarantees it offers consumers so in my opinion it is only a hack to work around a broken API. If the next version of Go deprecated it, there would be no way to write a middleware with config-specific elements that doesn´t leak due to missing lifecycle events. The problem would exist with or without yaegi, so I expect the same problem with upcoming webasm API.

from traefik.