On Tue, Nov 5, 2013 at 1:30 PM, Pavel Levshin <[email protected]> wrote:
> > And once more the same subject. > > If queues used in rulesets are main queues, and ruleset can be called in > the same way as action does, then definitely yes, there should be direct > mode. This queue is identical to action queue, then. > > For input modules, almost the same behaviour can be achieved with very > small queue size (down to 1 message). Yet another thing that I obviously need to prohibit. I don't even know if such a small "queue" works at all. If it does, the performance will be extremely bad. > Maybe I'm wrong on this matter, but direct mode input can be used to > guarantee message processing. Nope, it's just a different point where messages are dropped. If you have a queue, the queue will drop on queue full. If it is in direct mode, the queue will drop nothing, but then of course the input itself will not see anything. For tcp, it will pushback to the sender (just as a properly-configured queue for this use case does -- and I am not saying this is the best idea...).. For UDP, the kernel will drop message. So no guarantee at all. In any case: I have realized that it is probably more effort to discuss this than to continue to support it, so let's spare that effort. Rainer I'm not sure if this is implemented in RELP. Asynchronous queue cannot > guarantee anything. > > -- > Pavel Levshin > > > 05.11.2013 15:37, Rainer Gerhards: > >> Just as the subject says: do we need this? >> >> In some engine versions this was useful to limit locking contention, but >> that's not really a problem any longer. I am tempted to remove support for >> it (would clean up the code). >> >> Any thoughts? >> >> 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. >> > > _______________________________________________ > 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.
