Hello all,
I am sending you a set of patches that return the ability to use
haproxy variables to transfer opentracing context.
01 Revert "MINOR: opentracing: change the scope of the variable
'ot.uuid' from 'sess' to 'txn'"
02 MINOR: opentracing: only takes the variables lock on shared entries
03 CLEANUP: opentracing: removed unused function flt_ot_var_unset()
04 CLEANUP: opentracing: removed unused function flt_ot_var_get()
05 CLEANUP: opentracing: added flt_ot_smp_init() function
06 BUG/MINOR: opentracing: setting the return value in function
flt_ot_var_set()
07 CLEANUP: opentracing: added variable to store variable length
08 DOC: opentracing: corrected comments in function descriptions
09 MINOR: opentracing: improved normalization of context variable names
10 DEBUG: opentracing: show return values of all functions in the debug
output
11 CLEANUP: opentracing: added FLT_OT_PARSE_INVALID_enum enum
12 DEBUG: opentracing: display the contents of the err variable after
setting
13 EXAMPLES: opentracing: refined shell scripts for testing filter
performance
14 MAJOR: opentracing: reenable usage of vars to transmit opentracing
context
15 Revert "BUILD: opentracing: display warning in case of using
OT_USE_VARS at compile time"
16 BUG/BUILD: opentracing: fixed OT_DEFINE variable setting
Here I will explain only what is most important for this set of
patches.
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 |
+-----+---------------+-- .. --+-----+---------------+
This means that the maximum length of the variable name to be saved is
255 characters, which is quite enough for use in the filter. The
buffer size for such data storage is global.tune.bufsize.
In terms of code execution speed, this way of using context variables is
significantly faster than the previous one (when variables with names
were stored instead of hash). For example, in the worst case, when the
rate-limit is set to 100%, the operating speed is almost doubled (this
refers to the first result in the 'addons/ot/test/README-speed-ctx'
file).
Best regards,
--
Miroslav Zagorac
Senior Developer
