On Fri, Oct 25, 2013 at 10:42 AM, David Lang <[email protected]> wrote: > 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<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} > > you are right, that use case breaks. Thanks! I'll review mmcount in more depth now and see how it is actually used.
The ability to support subtrees can be added, but will be relatively expensive. > > 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. > Could be done, but (probably) requires some time. Also note that these counts are NOT accurate - so they are only good if a rough number is used. Keeping them accurate would very considerably slow down the engine. But it definitely makes sense to have them available, for other uses as well (think about switching from one output to another based on the number of messages inside the main queue). I'd still consider this as a new feature request. > > > 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) > I don't think so, as with each of this "copies" I would need to update work flags (like modifiable) for all variables. Also, I need to know which one is actually shadowed, so that would be a new flag (currently, it is just a failed lookup on the shadow dictionary). My assumption (I should have spelled this out) is also that we have a very low number of state variable updates, and even a low number of read accesses to them. Rainer > David Lang > > > ______________________________**_________________ > rsyslog mailing list > http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog> > http://www.rsyslog.com/**professional-services/<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. > _______________________________________________ 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.
