Hi Carlos, > Each object implements a connection pool maintaining multiple opened > connections in its internal state. I would like to be able to release those > connections when the VCL using the VMOD is not active: > > - I think that's not doable in 4.0. The only alternative is waiting for > the VCL to be discarded and then close connections when the __fini() callback > is executed for each instance.
In 4.0 you don't go through the __fini functions until the VCL is actually discarded. There's no way[1] to reliably release resources when the VCL is not active, only to release them when the VCL is discarded. > - In 4.1 we have the VMOD event function. The VMOD could listen for > VCL_EVENT_COLD events and then close established connections. In order to do > that the full list of instances would be required. Is it possible to get > access to that list somehow? Should it be manually implemented by the VMOD? > Is there any plans to propagate VCL temperature events also to object > instantiated by a VMOD? This has been discussed and events are not propagated to VMOD objects so you need to keep track of them and do the event propagation yourself. From what I remember, there are no plans to send events to objects (they still follow an init/fini style) or other data structures such as private pointers (PRIV_VCL). Be aware that VCL temperature is racy in 4.1.0 and that some of the issues have been fixed in master and others are awaiting a review. During the review, we found new holes in the design that need to be discussed: what do we do with VCLs that fail to load or warm up when the child is started? What do we do if the active VCL fails? Cheers, Dridi [1] that I know of _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
