On Fri, 25 Oct 2013, Rainer Gerhards wrote:
Hi all,
I thought out the details of what I have on my mind and think the solution
can work and support all known use cases. I've also managed to write it
down this morning:
http://blog.gerhards.net/2013/10/a-proposal-for-rsyslog-state-variables.html
I would appreciate if you could check it and see how the spec can be
technically broken or identify use cases which it will not be able to
handle.
One case I don't think it can handle is the current work that mmcount is doing.
As I understand mmcount, it creates a counter for each appname that it sees, and
uses that to count how many times that appname has been seen.
the fact that you can use $/a!b lets you have the variables without having the
conflict with anything else,
but you end up with no way to know what variables exist
you can't output the entire set of counts without being able to use $/a
you can't even lookup the count for the current message's appname without being
able to use domething like $a/{$appname}
Also, as a slight tangent, if it's possible to have mmpstats variables available
as global variables (or similar) then much of the manual counting may not be
needed as the pstats counters could be used instead.
depending on how large the table of global variables ends up, I wonder if it
would be easier (and because of the simpler design, possibly even faster) to
just make a shadow copy of all global variables at the start of the message
processing, (I'm thinking the RCU read-copy-update) mechanism may be a good fit
for this)
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.
