> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com
> [mailto:rsyslog-bounces@lists.adiscon.com] On Behalf Of Luis
> Fernando Muñoz Mejías
> Sent: Friday, March 20, 2009 6:02 PM
> To: rsyslog@lists.adiscon.com
> Subject: [rsyslog] Starting a native Oracle output module
> (was Re:Documentation on writing rsyslog modules?)
>
> El Miércoles, 18 de Marzo de 2009 11:04, Rainer Gerhards escribió:
> > When you are ready, I'd actually suggest that I create an
> "omoracle" git
> > branch for you and do place a copy of ommysql into it.
> This, together with
> > the comments from omtemplate, would probably one way to get
> a (non-optimal)
> > quick start.
> >
> So, I'm starting it and I already have something that compiles. Next
> step is to have something I can test, then have something that makes
> something, then something that does the same but fast.
>
> > I would suggest that we build a very basic oracle driver
> first and after we
> > see it works well, then look into the performance optimization.
> >
> That's my idea, too. I want something that:
>
> 1) Connects to the DB at createInstance() time.
> 2) Runs the un-prepared statement passed as template on each syslog
> entry.
> 3) Disconnects only at freeInstance() time.
>
> Prepared statements and batch operations will be added later, indeed.
>
> But first, I'd like to know what ways I have to test my module, other
> than recompiling it, installing and restarting rsyslog for
> each change.
You can run rsyslog interactively, that's the key to a useful testing
environment. In my development environment, I have a couple of conf files,
and a shell script that starts rsyslogd in a variety of test settings (don't
forget about running valgrind on it frequently, it safes you a lot of time
;)). I am not at my devel machine right now, but the core command looks
something like
cp "all plugins" runtime/.libs # or so
./tools/rsyslogd -dn -c 4 -f myconf.conf -M runtime/.libs ... Maybe some
more...
Then you run rsyslogd for your test, and press ctl-c when you are done. My
cycle is
Loop
edit
make
run-script
End Loop
Does this help?
Oh, and I have disabled the regular rsyslogd on that devel box. If you don't
do, you probably need to add some extra quirks to it. I have also begun to
work on some tcl-based tests yesterday, hope to have them in git mid next
week.
Rainer
>
> > Let me know what you think (and when you have time).
>
> I'm already on it. I hope to deliver something for review next week.
:)
>
> Cheers.
> --
> Luis Fernando Muñoz Mejías
> Luis.Fernando.Munoz.Mejias@cern.ch
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
> From: rsyslog-bounces@lists.adiscon.com
> [mailto:rsyslog-bounces@lists.adiscon.com] On Behalf Of Luis
> Fernando Muñoz Mejías
> Sent: Friday, March 20, 2009 6:02 PM
> To: rsyslog@lists.adiscon.com
> Subject: [rsyslog] Starting a native Oracle output module
> (was Re:Documentation on writing rsyslog modules?)
>
> El Miércoles, 18 de Marzo de 2009 11:04, Rainer Gerhards escribió:
> > When you are ready, I'd actually suggest that I create an
> "omoracle" git
> > branch for you and do place a copy of ommysql into it.
> This, together with
> > the comments from omtemplate, would probably one way to get
> a (non-optimal)
> > quick start.
> >
> So, I'm starting it and I already have something that compiles. Next
> step is to have something I can test, then have something that makes
> something, then something that does the same but fast.
>
> > I would suggest that we build a very basic oracle driver
> first and after we
> > see it works well, then look into the performance optimization.
> >
> That's my idea, too. I want something that:
>
> 1) Connects to the DB at createInstance() time.
> 2) Runs the un-prepared statement passed as template on each syslog
> entry.
> 3) Disconnects only at freeInstance() time.
>
> Prepared statements and batch operations will be added later, indeed.
>
> But first, I'd like to know what ways I have to test my module, other
> than recompiling it, installing and restarting rsyslog for
> each change.
You can run rsyslog interactively, that's the key to a useful testing
environment. In my development environment, I have a couple of conf files,
and a shell script that starts rsyslogd in a variety of test settings (don't
forget about running valgrind on it frequently, it safes you a lot of time
;)). I am not at my devel machine right now, but the core command looks
something like
cp "all plugins" runtime/.libs # or so
./tools/rsyslogd -dn -c 4 -f myconf.conf -M runtime/.libs ... Maybe some
more...
Then you run rsyslogd for your test, and press ctl-c when you are done. My
cycle is
Loop
edit
make
run-script
End Loop
Does this help?
Oh, and I have disabled the regular rsyslogd on that devel box. If you don't
do, you probably need to add some extra quirks to it. I have also begun to
work on some tcl-based tests yesterday, hope to have them in git mid next
week.
Rainer
>
> > Let me know what you think (and when you have time).
>
> I'm already on it. I hope to deliver something for review next week.
:)
>
> Cheers.
> --
> Luis Fernando Muñoz Mejías
> Luis.Fernando.Munoz.Mejias@cern.ch
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com