On Thu, Jan 15, 2015 at 9:28 PM, David Lang <[email protected]> wrote: > I'm missing something here. If rsyslog has a queue for the destination, > and the delivery to the destination is via TCP, how is a pull any better > than a push? if the destination accepts data at a faster pace than it can > really handle, why would the pull be any better? If the destination only > accepts data at the rate it can handle, then the traffic will backup into > the rsyslog queue
Hmmm... that's a good point (and I have a feeling you brought it up before, too :p). Though I can't help thinking that centralized control over when a new batch is pulled has its advantages. For instance, you do some reports at night, you know you're going to take some stress, so you pause pulling or make it run slower. Sure, one can do that with cron on N rsyslog machines, too, but I guess such an argument can continue forever. Either way, I'm glad to see that there are other points in favor of having a pull model as well (like firewalls). Best regards, Radu _______________________________________________ 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.
