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

[Ryan Burn]

I think that might be what I'm looking for. Is there any function like
VRT_r_resp_status, but that operates on the request object instead of
the context, to let me extract the status code sent?

On Sun, May 21, 2017 at 11:56 AM, Guillaume Quintard
<guillaume at varnish-software.com> wrote:
> 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
>
>