When there are multiple VCLs loaded would they all be exposed via VSM? I think kicking off a child to do the work only when necessary would be better and you get the auth check bonus.
On Tue, Jul 22, 2014 at 10:08 AM, Poul-Henning Kamp <[email protected]> wrote: > In message <CAEh05Va0upueb8CDQEdNh=NXhpf_= > [email protected]> > , Dag Haavi Finstad writes: > > >As discussed on the Stockholm VDD, here's a proposal for #1457. > >[...] > >The VCLs are output in the same order as they appear in the VCL > >location/profiling table in the compiled VCL (the vcl->ref stuff used > >in the VCL_trace records), so if someone wanted to do a VCL code > >tracer thing, that should be possible. > > I'm not at all happy with the fact that we still dlopen() VCL's for > vcl.show(). That exposes the master process in ways I don't like, > even more so now we have VMODS which pull in strange libraries. > > One way to fix it is to accept that we cannot show the source > unless the child process is running. I can live with that. > > If that is not acceptable, we could fork a child of master to > dlopen() the compiled VCL (we already do that for testing) and > pull the source out of that. > > But all in all I prefer to make the child responsible, so that > we don't dlopen() compiled VCL's unnecessarily. > > If we go that route, we can do as now, and only exposed it via > VCL or we can expose the counters and VCL source via VSM to > avoid the VCL overhead. > > The latter is probably best for interactive visuals, but does > expose the VCL source without CLI auth check. I'm not sure > if that is OK. > > Input ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [email protected] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > varnish-dev mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev >
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
