On Mon, Oct 21, 2013 at 12:07 PM, Rainer Gerhards <[email protected]>wrote:
> On Mon, Oct 21, 2013 at 10:42 AM, Rainer Gerhards < > [email protected]> wrote: > >> On Mon, Oct 21, 2013 at 8:52 AM, Rainer Gerhards < >> [email protected]> wrote: >> >>> On Sun, Oct 20, 2013 at 6:03 PM, Pavel Levshin <[email protected]>wrote: >>> >>>> >>>> I am unable to reproduce this behaviour with global variables. This is >>>> what I've tried among others: >>>> >>>> if $/zz % 3 == 0 or $/zz % 3 == 1 then { >>>> set $/zz = $/zz + 1; >>>> action(...) >>>> } else { >>>> set $/zz = 0; >>>> action(...) >>>> } >>>> >>>> Could you please explain how is it supposed to work? >>>> >>> >>> It's supposed to work just as you describe it. But indeed, it doesn't do >>> so, I can reproduce the problem. Looks like a regression. Thanks for >>> reporting, will now look into it. >>> >> >> OK, looks like I stumbled into my own trap. In script, you access >> properties via $<propname>. Global variables have the name $/zz (with zz >> being the real name). So to access them, you need to access $$/zz. >> >> I think I got confused about this some time ago, and the doc is also not >> correct or at least inconsistent. I now need to work my way through that >> mess. Just thought I give you some explanation. >> > > ... and it gets even worse: when I quickly implemented global vars before > my vacation, I did not fully think out the implications :-( > > The use case then was to have some incrementing counters. That works. > However, due to the way the rule engine works, this use case here does not > work as expected. The reason is that the rule engine is a SIMD machine: it > applies all operations to all message inside the batch. As such, it does > the if-evaluation on the whole batch, then the variable increment, than the > action and so on. It works this way because this is a very big performance > gain. However, this means when zz is 0 at start of a batch of 10 messages, > the if will work with 0 for all 10 of them. Then, zz will be ten times > incremented, leding to value 10. Then, the action is executed (10 times). > > I am not sure what the proper solution is. The most clean solution would > be to remove support for global variables, the best but very costly would > be to enhance the engine to have a special execution mode (much slower) for > statements that involve global variables. The quick and dirty solution is > to leave everything as is- but document this behaviour -- as there are > valid use cases for the current state. > > I think I will take the "just document" path for now, and think about > removing global variables (after all, so far they are only in the > devel/experimental tree). Comments are appreciated. > > @Pavel: did you check that mmsequence actually works as you expect? IMHO > it should expose the same behaviour as global variables. > > yeah, mmsequence works, and it does so because it kind of atomically increments the global count saves this value to the message variable. If I had already implemented that (planned) function, you could do the same thing in scripting via set $$!msgctr = atomic_inc($$/zz); and use $$!msgcntr for the rest of the checks. Rainer _______________________________________________ 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.
