[Varnish] #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values

Varnish varnish-bugs at varnish-cache.org
Fri Nov 29 14:23:35 CET 2013


#1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with
uninitialized values
------------------------+--------------------
 Reporter:  geoff       |       Owner:
     Type:  defect      |      Status:  new
 Priority:  high        |   Milestone:
Component:  varnishlog  |     Version:  3.0.3
 Severity:  major       |  Resolution:
 Keywords:              |
------------------------+--------------------

Comment (by geoff):

 Just spoke to Martin (at VUG8). Both of these phenomena (uninitialized fd
 and spec in the VSL_Dispatch call) are known issues in the Varnish 3 log
 API.

 The file descriptor may have been closed in client connections, and Martin
 mentioned that there are certain situations where ESI requests don't have
 a proper fd (don't remember the details). So by the time log entries for
 client transactions make it to the log, the fd may be -1. That fits with
 my experience that this only ever seems to happen for client logging.

 The spec field might not be set because the Varnish 3 API (in VSL_NextLog)
 attempts to guess whether a vsm is associated with a client or backend by
 looking for tags that can only come from one or the other: ReqStart and
 SessionOpen for clients, BackendOpen and BackendXID for backends. In
 certain situations, none of those tags might have been seen (and
 BackendXID is never used).

 All of these issues are solved in the Varnish 4 API.

 So there really isn't any solution for this in Varnish 3, short of looking
 for fixes in the logging API (which are probably not trivial).

 An application using the API may decide that if fd == (unsigned) -1, then
 the client has been disconnected, so the data doesn't need to be logged.

 If spec is not set, an app can try harder to guess whether it's a client
 or backend based on the tag, because there are more than just those four
 tags that are strictly for backends or clients (my apps do that).

 Or migrate to Varnish 4. %^)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1330#comment:2>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator




More information about the varnish-bugs mailing list