On Tue, 22 Oct 2013, Pavel Levshin wrote:
22.10.2013 16:26, David Lang:
mmglobal is going to need to store it's data somewhere, have that somewhere
be the $/ namespace like we had in 7.4.4 instead of having to modify each
message's variable space with all the global variables.
This sounds good. And this $/ namespace could be accessible from other
plugins to allow for future expansion. The same for locals.
all plugins can already access $! and $. message variables.
having other plugins access global variables sounds more risky, the rules to
access them need to be very specific due to locking. I could see some things
happening (like possibly putting the pstats data into this namespace so it can
be accessed directly???) but such use should be very carefully thought out.
Then, there is need for each global variable to be lockable. But then, it can
lead to a deadlocks...
each global variable needs to eithe be lockable or manipulated with atomic
statements.
don't allow global variables to be used in anything other than the right
hand side of a set statement (if you care about it, you set a message
variable equal to the global variable, and then refer to the message
variable in your if or template statement). This should avoid all the loop
unrolling problems
It is unnatural for a function, which returns value, to not work in every
expression. This is why action may be better than function. But actions, of
course, also are not well-suited for message modification; they have many
properties which are designed for output modules.
Rainer is saying that he thinks they may be able to be used in if statements,
you already can't use functions in templates, so I don't see that as a problem.
my $/varname is the equivalent of the function getvalue(var='varname'), which is
why it can't be used in all the places that $!varname could be used.
I'm on the fence as to which is better. I like the shortness and simplicity of
$/varname, but I can see the attraction to getvalue() or similar instead to make
it clear that it's not something that you can set.
Let's see.
Then require function calls to change anything in the global namespace
It sounds like we would need something similar to the following set of
functions
globalset(var='$/varname' subvar='$property!or!string' value='string or
number');
globalinc(var='$/varname' subvar='$property!or!string' step='number default
1');
globaldec(var='$/varname' subvar='$property!or!string' step='number default
1');
globalinc and globaldec is the same, step can be negative. I've made steps
non-negative in mmsequence, because I was unable to think out any use case
for decrementing.
I agree with combining them, I don't see a reason to eliminate negtive values.
I'm not sure where I'd use them, but I'm also sure that as soon as it's locked
in stone that they can't be negative, someone will find a case where they need
to be :-)
And, I really love idea of ranges for sequences, to make them bounce within
known borders. Modulus is more ugly.
well, a range is just offset + counter % span, I'd rather just let the user do
the math. I want to do as little as possible in the function. In fact, I'm very
tempted to make step be -1 or 1 only, simply because that can be done with a
single atomic instruction rather than needing to lock the variable (setting is
inherently racy with other threads stepping it)
We don't really need var and subvar as separate parameters, if we can
generate the name of global variable dynamically. Say, with a template. Of
course, it is no good for performance. But you are going to evaluate
properties anyway.
right now nothing in rsyslog allows properties as part of variable names, and we
do need to be able to have some way to embed per-message current values of
properties in the variable names. If we can do it as one value that can embed
properties or other variables as part of it, great!! (that's what I'm talking
about when I talk aobut $.varname!{$hostname} and similar)
this would let you set a string variable, set and use a counter, including
counting based on the contents of a message
so if you wanted counts per hostname you would do something like:
globalinc(var='$/hostcounts' subvar='$hostname')
which would create $/hostcounts!<hostname> variables as needed.
when you want to use these counts, you can
set $.myhostcounts = $/hostcounts;
and then use them in the message
Then you would need something like
globalReportReset(var='$/varname')
that you would use instead of $/hostcounts in the set above that would
atomically set $.myhostcounts and then destroy all the variables (the reset
portion)
And it is good approach, because this way you can report all counters at
once. I just still sceptical about usage of functions here.
I'm not just thinking of getting all values at once, but also zeroing them all
at the same time.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
