VIP23 (VSL refactoring) design sketch

[Nils Goroll]

On 12/04/2019 16:37, Dridi Boukelmoune wrote:

> Interesting, for textual logs the effect of vsl_reclen is
> straightforward but how should we deal with binary records truncation?

As before - truncate?

For the fixed part, we can make sure that vsl_reclen can not be set to below a
sensible minimum, and I do not see a difference between truncating text and
binary. In both cases the log is just - a log, and may lose data anyway.

> Should we though? If someone runs Varnish in a virtual machine on a
> mainframe server and runs varnishlog -w don't we want to be able to
> varnishlog -r that file on a "regular" workstation?

Ideas of a BOM and a double representation marker were mentioned before. We
would indicate in the log which representation was used and it would be up to
the client to make any endianness adjustments, double representation conversions
and the like.

> Having null-terminated strings open a zero-copy opportunity on the VSL
> consumer side.

Agree.

Nils

-- 

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20190412/b4d98a5b/attachment.bin>