Hmm. That's a tougher question. On the one hand I can see the benefit to it. But on the other hand, is it the best choice for location... One could argue that processing scripts like that should be in their own repo since they are not directly linked to the Rsyslog codebase.
-- James -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rainer Gerhards Sent: Wednesday, January 22, 2014 9:31 AM To: rsyslog-users Subject: Re: [rsyslog] non-C output plugins sorry for being so imprecise... What I meant to ask is if we should place such non-C plugins into the main rsyslog repo. I see lot's of good in this (assuming the contributor is happy with that, of course), but that means that changes can only go into them via PR, patches... Rainer On Wed, Jan 22, 2014 at 4:07 PM, Boylan, James <[email protected]>wrote: > It seems to me that if it's either added as a modification to omprog > or a new ompipe then having it added to master as a default disabled > option should work. Less maintenance overhead and is available for use. > > -- James > -- Sent from my mobile -- > > ----- Reply message ----- > From: "Rainer Gerhards" <[email protected]> > To: "rsyslog-users" <[email protected]> > Subject: [rsyslog] non-C output plugins > Date: Wed, Jan 22, 2014 9:04 AM > > On Wed, Jan 22, 2014 at 4:02 PM, Rainer Gerhards > <[email protected]>wrote: > > > On Wed, Jan 22, 2014 at 3:59 PM, Boylan, James > ><[email protected] > >wrote: > > > >> I agree with everyone that omprog should be a good solution for this. > I'm > >> going to be doing some tests in the near future with omprog so I'll > >> be looking at Radu's post as well. :) > >> > >> Mostly I think using a stdout pipe is a good way of handling this. > >> It is similar to how Hadoop handles non-Java mapreduce jobs as well. > >> > >> > > A key thing to note is that a pipe is a quite efficient > > inter-process communication facility and also includes some built-in > > flow control (so > the > > reading end of the pipe can push back the writer). Of course, it > > requires additional context switches, but that should not be too bad. > > > > An interesting thought is to write a simple write-to-file script and > > measure it's performance vs. omfile. That should be an indication of > > the actual pipe overhead, especially if /dev/null is written to... > > > > > Better even: a native C program, so that we don't measure language > runtime overhead... > > Question in this regard: should all of this go into the main repo? > There are pros and cons... > > 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. _______________________________________________ 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.
