On Tue, Nov 5, 2013 at 2:28 PM, Pavel Levshin <[email protected]> wrote:
> > 05.11.2013 13:23, David Lang: > > >> To summarize: current call behaviour makes perfect sense (because call >>>> implies return), but, to be consistent, ruleset objects should not >>>> contain >>>> queue as a property. Or, at least, there should be warning when the >>>> queue >>>> is not of "direct" type. >>>> >>>> And then, possibility to resubmit a message into another queue is also >>>> helpful. It can be done externally (via omfwd/imudp, for example), but, >>>> for >>>> performance reasons, it is certainly better to do this internally. >>>> Maybe, >>>> omruleset is the right way to go, it only lacks possibility to pass the >>>> message by reference for better performance. >>>> >>> >> I disagree, I think both types make perfect sense, but for different >> situations. >> >> > Where is this disagreement? :) Did I say something differently? > > > call/return (i.e. direct queue) makes sense when you are using the >> ruleset to simplify your config by taking some thing that you may have to >> do many places in the rules and only enter them once (or where you want to >> output to one file from many places in the rules, after different >> manipulation has been done to the message) >> >> async call (i.e. non-direct queue) can be used in many of the same places >> that call/return can be used, but it can also be used for many cases there >> it won't work (say you are sending to remote machines and you want to limit >> the total disk space used by your queues, you are stuck either using a >> single queue, or doing a queue per destination where you may have messages >> duplicated in the different queues) >> >> In fact, I think the cases where call/return matters (i.e. something in >> the ruleset modifies the message and then things outside the ruleset depend >> on the change) are probably the rarer need >> > > It's all correct. What I've said is that "async call" could be named > differently. "Spawn", for example. Because in most programming languages > "call" implies return, and in Rainerscript it was so... till this day. The > problem is, you cannot reliably tell what a "call" does, can it change the > message and return, can it delay processing (due to some action in remote > ruleset) or not, if it is just "call" for every case. > > Let me re-iterate that I am *not* intending to write a full-featured programming language. There was some flexibility and power in rule processing desired. I don't think we are on the right path if we could just add a syslog server library to perl. If we actually desire that functionality-wise, doing this type of implementation would be the better path to go. > But now - we already have async "call", just like docs said before. Btw, > it copies the message, just like omruleset. > > yup, because you can't get the benefit without the cost. Submiting to a queue is costly and copying the message is the only decent thing you can do at the current state of implementation. Note that you are not forced to run the ruleset asynchronously. Actually, I'd strongly recommend against this for rulesets used as call target, but that's too late now. Rainer > > -- > Pavel Levshin > > _______________________________________________ > 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. > _______________________________________________ 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.
