On Tue, Oct 22, 2013 at 1:09 PM, David Lang <[email protected]> wrote: > well, I wouldn't want to have the module store a counter into the $! > namespace, too much chance of conflicting with something from a message, > and if I've got several things stored (for different purposes), I don't > want them to all show up when I output $! >
let the user decided. For this, we have local vars. > > store it in $. or in some different namespace (say $/ ;-p ) > > for counting and sequence numbers this sounds reasonable. > > but what are you thinking about for storing other values? I'm expecthing > that most of these other values will be strings. > What's the difference? e.g. (just psedudocode) action(type="globals" key="mykey" value="some string" store_to=".localvar") it may be useful to implement this as function rather than action or even a totally new object -- makes integrating with expressions much easier (for outputs, you must always go through a template). But the 7.5.4 globals vars cannot do this, as you cannot attach semantics to them that *force* to write to a local var -- this is the root problem. Rainer > > David Lang > > > On Tue, 22 Oct 2013, Rainer Gerhards wrote: > > Summing this up, I conclude: >> >> * global vars, as they are currently implemented, need to go away >> * they can probably be replaced by an enhanced mmcount (mmglobal) >> >> Such an mmglobal would unite the functionality of mmcount, the proposed >> mmsequence and something that just stores some properties for later reuse. >> The important thing about it is that it will always store the current >> global value to a *message variable*. Such a module will be able to handle >> all the use cases so far described. >> >> In doc, we can say that global variables have been removed as they do not >> work well, and have been replaced by mmglobal (or whatever we call it). >> >> How does that sound? >> Rainer >> >> >> On Tue, Oct 22, 2013 at 12:20 PM, Pavel Levshin <[email protected] >> >wrote: >> >> 22.10.2013 13:37, David Lang: >>> >>> >>> I think that if you just document that setting global variables is racy, >>> >>>> and as such it's not suitable for accruate counting, only for changing >>>> rsyslog behavior without a restart you should be good on the >>>> expectations >>>> front. the current documentation leans heavily on the counting aspect of >>>> things, but that can be changed. remove any suggestion of future atomic >>>> opertations and emphisise that atomic operations are not possible. >>>> >>>> >>>> I think they are not suitable for counting at all. Only some particular >>> cases may be possible, but I cannot visualize one currently. >>> >>> >>> being able to enable or disable e-mail messages, change what the >>> >>>> destination address is, change the filename or patch when the box >>>> becomes >>>> active are all very useful items that I would hate to loose. >>>> >>>> >>>> Absolutely agree. This is valid and interesting application, exactly as >>> you describe this. >>> >>> >>> even the load balancing hack works 'well enough' once you accept that >>> you >>> >>>> are balancing per batch rather than per message (even if you did balance >>>> per message, you really have no idea how expensive a particulare >>>> message is >>>> going to be, so you are not really balancing the work precisely, you are >>>> only doing so statistically, and balancing per batch rather than per >>>> message is just as valid statistically) >>>> >>>> >>> No, it will not work in general. Suppose you have a batch of 256 and 8 >>> actions to select. 256 divides by 8, so you will put all you load on just >>> one server. Selecting "right" numbers is hard. >>> >>> >>> -- >>> Pavel Levshin >>> >>> >>> ______________________________****_________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/****mailman/listinfo/rsyslog<http://lists.adiscon.net/**mailman/listinfo/rsyslog> >>> <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/> >>> <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://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://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.
