Since commit 3a4bedccc ("MEDIUM: vars: replace the global name index with
a hash") the names of HAProxy variables are no longer saved, ie their
64-bit hashes are saved instead.
This is very convenient for the HAProxy itself, but for the OpenTracing
module it is a problem because the names of the variables are important
when transferring the OpenTracing context. Namely, this context consists
of an unknown amount of data stored in a key-value format. The number
of these data (and the name of the variable used for this purpose) is
determined with the configuration of the OpenTracing filter, as well as
with the tracer used. The two previous sentences seem to be in conflict,
but that is only so at first glance. The function in the OpenTracing
filter used to read the context does not really know this, neither their
number nor its name. The only thing that function actually knows is the
prefix of the variable names used for context transfer, and by that it
could find all the necessary data. Of course, until the application of
the above-mentioned commit.
The problem is solved in a very simple way: in a common variable that
the filter always knows its name, the names of all variables that are the
product of the OpenTracing context are saved. The names of these context
variables can only be added to that common variable. When that variable
is no longer needed (when we no longer need context), it is deleted.
The format for saving data to this common variable is as follows:
+-----+---------------+-- .. --+-----+---------------+
| len | variable name | | len | variable name |
+-----+---------------+-- .. --+-----+---------------+
The amount of memory space used to store the length of the name is 1 byte,
with a sign (the minus sign is provided for inactive records, but this is
not currently used). This means that the maximum length of the variable
name to be saved is 127 characters, which is quite enough for use in the
filter. The buffer size for such data storage is global.tune.bufsize.
This patch must be backported in 2.5.
If the OpenTracing filter is compiled using the 'OT_DEBUG=1' option, then
log messages are printed to stderr when the filter is running. In the log
one can then find (among other things) the order in which the function is
called and the value that the function returns (if it is not a void type).
Prior to applying this patch, no value returned by a function was logged.
Log output example:
[ 1] 0.038807 [OT]: flt_ot_init_per_thread(0x56365bd45ec0, 0x56365bd48210) {
[ 1] 0.038807 [OT]: ot_start(0x56365bd58920, 0x56365bd4e3a0, 0x7f561acba168:(nil)) {
[ 1] 0.038807 [OT]: } = 0
[ 1] 0.038807 [OT]: } = 0
This patch must be backported as far as 2.4.
The flag_cpy parameter has been added to the flt_ot_normalize_name()
function, through which we can determine whether the function converts
special characters (which are part of that name) when copying a variable
name.
This patch must be backported in 2.5.
The same variable should not be used to store multiple different results,
because it can be confusing. Therefore, the var_name_len variable has
been added in several functions, in order to avoid the use of the retval
variable for several different purposes.
This patch must be backported as far as 2.4.
The flt_ot_smp_init() function has been added to make initializing the
sample structure easier. The contents of the structure in question are
set in several places in the source of the OpenTracing filter, so it is
better to do this in one place.
This patch must be backported as far as 2.4.
Regarding commit #61ecf2838:
There's no point taking the variables locks for sess/txn/req/res
contexts since these ones always run inside the same thread anyway.
This patch must be backported in 2.5.
The flt_ot_var_get() function is not used anywhere and is unnecessary
in the existing implementation of the OpenTracing filter.
This patch must be backported as far as 2.4.
The flt_ot_var_unset() function is not used anywhere and is unnecessary
in the existing implementation of the OpenTracing filter.
This patch must be backported as far as 2.4.
Function flt_ot_var_set() did not check whether the variable was
successfully set or not. In case of failure, the value -1 is returned.
This patch must be backported as far as 2.4.
The API was extended by commit e352b9dac ("MINOR: vars: make vars_get_by_*
support an optional default value") but I didn't notice that opentracing
was using it, so it broke the build. No backport needed.
The presence of this field causes a long dependency chain because almost
everyone includes global-t.h, and vars include sample_data which include
some system includes as well as HTTP parts.
There is absolutely no reason for having the process-wide variables in
the global struct, let's just move them into vars.c and vars.h. This
reduces from ~190k to ~170k the preprocessed output of version.c.
This one is the last optional module to build with haproxy, so let's move
it to addons/. It was renamed to "ot" as it was the only one whose USE_*
option did not match the directory name, now this is consistent.
Few changes were required, only the Makefile, and doc were adjusted, as
the directory was already self-contained and relocatable.
