Aaron, Thanks for your feedback.
> Another thing you might want to think about is the idea of using a > callback timer, as was outlined for another prospective feature > implementation here: http://www.rsyslog.com/Article334.phtml I'd like to, indeed. But it's lower priority to me. The volume of the data sources I'm pushing into Oracle is *really* high. Then, if I stick to a single big batch, I can let the core do the actual batch management. Otherwise, I need either to receive things in very small batches that I concatenate or to call the core to dump its internal buffer. Both are doable, but require some work I'd rather not do right now. O:) > The general idea being, while having a batch size is important, if you > don't have some functional timer callback to the output module, you > will end up in the situation of not flushing regularly. On > lower-traffic outputs, this would reduce the risk of losing a lot of > data. So you could have two different mechanisms: > What I'd suggest is to have several batch sizes for different selectors: $OmoracleBatchSize 1000 if(large_volume_expression) then :omoracle:;LargeTemplateName $OmoracleBatchSize 1 if(really_small_volume_expression) then :omoracle:;SmallTemplateName This way, I don't need a timer to communicate with the core, and simplify my code. In the worst case scenario, SSH could suddenly stop working at the entire CERN and I'd lose the last 999 messages. I admit the critical information on why SSH stopped working is on those 999 messages, but for the moment I accept that risk. ;) Cheers. -- Luis Fernando Muñoz Mejías [email protected] _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
