Thank you for responding David and Rainer :)
With some help from a friend with better programming skills than me
the code responsible for the behaviour I observed has been identified.
The code was then modified, re-compiled and the module subsequently
tested to work as expected. The change required is in 'omoracle.c'
where the 'doAction' block of code was changed from:
------------------------------------------------------------------------
BEGINdoAction
int i, sz;
char **params = (char**) ppString[0];
CODESTARTdoAction
if (pData->batch.n == pData->batch.size) {
dbgprintf("omoracle batch size limit hit, sending into DB\n");
CHKiRet(insert_to_db(pData));
}
for (i = 0; i < pData->batch.arguments && params[i]; i++) {
dbgprintf("batch[%d][%d]=%s\n", i, pData->batch.n, params[i]);
sz = strlcpy(pData->batch.parameters[i][pData->batch.n],
params[i], pData->batch.param_size);
if (sz >= pData->batch.param_size)
errmsg.LogError(0, NO_ERRCODE,
"Possibly truncated %d column of '%s' "
"statement: %s", i,
pData->txt_statement, params[i]);
}
pData->batch.n++;
finalize_it:
ENDdoAction
------------------------------------------------------------------------
...to:
------------------------------------------------------------------------
BEGINdoAction
int i, sz;
char **params = (char**) ppString[0];
CODESTARTdoAction
for (i = 0; i < pData->batch.arguments && params[i]; i++) {
dbgprintf("batch[%d][%d]=%s\n", i, pData->batch.n, params[i]);
sz = strlcpy(pData->batch.parameters[i][pData->batch.n],
params[i], pData->batch.param_size);
if (sz >= pData->batch.param_size)
errmsg.LogError(0, NO_ERRCODE,
"Possibly truncated %d column of '%s' "
"statement: %s", i,
pData->txt_statement, params[i]);
}
pData->batch.n++;
if (pData->batch.n == pData->batch.size) {
dbgprintf("omoracle batch size limit hit, sending into DB\n");
CHKiRet(insert_to_db(pData));
}
finalize_it:
ENDdoAction
------------------------------------------------------------------------
Regards,
Damian
On Tue, Oct 2, 2012 at 7:59 AM, <[email protected]> wrote:
>
> On Mon, 1 Oct 2012, Rainer Gerhards wrote:
>
>>> enabling batching should not change this as rsyslog does not wait for a
>>> batch to be full before processing it, instead the batch is the maximum
>>> number of messages it will pull off the message queue to process at
>>> once.
>>
>>
>> IIRC, omoracle does it's own kind of batching, so it is disjunkt from
>> rsyslog batching. Not sure, though.
>
>
> Ok, that would explain many issues. It makes sense that since omoracle is
> older than batching mode it could have not gotten updated to match the more
> modern interface. It's a problem though in that it causes this type of
> problem.
>
>
>> If omoracle does not work, would it make sense to try omlibdbi? In theory it
>> should work with oracle, but I have not test environment at all to try this
>> out.
>
>
> One problem with omlibdbi is that I believe that it doesn't do any batching,
> it also disables all transactions on the database server, so you end up
> sacraficing a lot of the reliability that you are probably expecting to get
> from using a database in the first place.
>
>
> David Lang
> _______________________________________________
> 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.
