New parameters for mmkubernetes (module and action):
* `cacheexpireinterval`
If `cacheexpireinterval` is -1, then do not check for cache expiration.
If `cacheexpireinterval` is 0, then check for cache expiration.
If `cacheexpireinterval` is greater than 0, check for cache expiration
if the last time we checked was more than this many seconds ago.
* `cacheentryttl` - maximum age in seconds for cache entries
New statistics counters:
* `podcachenumentries` - the number of entries in the pod metadata cache.
* `namespacecachenumentries` - the number of entries in the namespace
metadata cache.
* `podcachehits` - the number of times a requested entry was found in the
pod metadata cache.
* `namespacecachehits` - the number of times a requested entry was found
in the namespace metadata cache.
* `podcachemisses` - the number of times a requested entry was not found
in the pod metadata cache, and had to be requested from Kubernetes.
* `namespacecachemisses` - the number of times a requested entry was not
found in the namespace metadata cache, and had to be requested from
Kubernetes.
macro used unsigned, inline function int. This could lead to an unsigned
overflow if macro version was used. That could potentially lead to malfunction
on some platforms (not seen nor expected in practice, though).
Detected by clang UBSAN.
During e.g. shutdown it could happen that a worker thread was started
and immediately be requested to terminate. In such situations there was
a race the prevented proper initialization. This could lead to follow-on
problems.
We believe (but could not proof) that this also could lead to a hang of
the termination process. Thus we claim to close an issue tracker down
here below, but are not 100% certain it really closes it (we hope for
user feedback on this). In any case, the thread debuger showed invalid
operations and this has been fixed, so it is useful in any case.
closes https://github.com/rsyslog/rsyslog/issues/1959
This is not a real problem because imdiag intentionally does multiple
tries to validate predicate validity. However, this is reported in
clang thread sanitizer and so we need to fix it.
this was previously not properly handeld. This is also the first occurence of
a (real) CAS loop inside rsyslog. Note that the performance is now very well
in the default configuration, and mark message directives are still correctly
being handled. So this code looks close to final, but needs to have some
bug cleanup as the testsuite shows.
replaced atomic operation emulation with new code. The previous code
seemed to have some issue and also limited concurrency severely. The
whole atomic operation emulation has been rewritten.
... but this is not considered a real solution. For some of the
uses, it may acutally be sufficient, but the implications need
to be analyzed in detail.
This may have caused a segfault under strange circumstances (but if
we just run long enough with a high enough message volume, even the
strangest circumstances will occur...)
There was a wrong order of mutex lock operations. It is hard to
believe that really caused problems, but in theory it could and with
threading we often see that theory becomes practice if something is only
used long enough on a fast enough machine with enough CPUs ;)
there are still some files left which could go into the
runtime, but I think we will delete most of them once we
are done with the full modularization.
This enables us to use more efficient calling conventions and
also helps us keep the on-disk structure of a msg object more
consistent in future releases.
