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://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.
