Any way to invoke code from VCL after a request has been serviced?

[Guillaume Quintard]

Best way I see for now is to capture a pointer to req in PRIV_TASK and use
is during the release/free operation. You should be okay since that
operation comes before the release of the req, but don't keep anything
after that step.

You'll lose some timing information, as well as the orignal http objects
(you'll get the vcl-transformed ones) though. Would that suffice?

-- 
Guillaume Quintard

On Thu, May 18, 2017 at 3:20 PM, Ryan Burn <rnickb731 at gmail.com> wrote:

> I don't see how that could work. The context for the active span needs
> to be injected into the headers of any backend requests. The headers
> need to be modified from the varnishd process, right? And you can't
> inject a span context unless the span has been created, so I would
> think a VMOD would have to start the span as well; then since the
> OpenTracing API to specify other properties of the span requires
> acting on the object returned when you start the span, those would all
> need to called from the VMOD.
>
> Also, none of the OpenTracing API functions should block for very
> long, if at all. The more expensive work such as uploading the tracing
> data would happen in a separate thread.
>
> On Thu, May 18, 2017 at 4:45 AM, Dridi Boukelmoune <dridi at varni.sh> wrote:
> > On Wed, May 17, 2017 at 11:07 PM, Ryan Burn <rnickb731 at gmail.com> wrote:
> >>> How about a VMOD doing the only StartSpan, std.log for logging keys
> >>> and whatnot, and the VUT doing all the rest when it processes the
> >>> transaction's logs?
> >>
> >> But the VUT would be running in a separate process, no? If so, how
> >> does it access the span object returned when you start the span. The
> >> OpenTracing API doesn't support augmenting information to a span
> >> later. The functions to set the tags, finish time, etc all have to act
> >> on the same object that's returned when you first start the span.
> >
> > You log whatever needs to ultimately be transmitted to the OT server
> > and let the VUT pick the logs and do the actual API calls. Performing
> > blocking (API) calls from VCL is also a performance killer, that's why
> > Varnish logs in memory and can let VUTs find what they need to do the
> > dirty work.
> >
> > Take varnishncsa for example. The varnishd process that is technically
> > the HTTP server doesn't do access logs and instead it's a separate VUT
> > that picks up the relevant information from the shmlog to produce
> > them.
> >
> > Dridi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170521/2cc0adcc/attachment.html>