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. @Paval: did you check that mmsequence actually works as you expect? IMHO it should expose the same behaviour as global variables. 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.
