Hello.
If it was true, I would expect to never see normalized messages. But
they are there from time to time.
But if it is true, then queues are counterproductive for message
modification. I think, if so, queueing should be prohibited in software
for such modules. And then, all CPU intensive processing would be done
from main queue only?
--
Pavel Levshin
19.10.2013 19:05, David Lang:
Second, in 7.5.5, this does not work at all. In 7.4.4, mmnormalize
produces expected output, though it cannot keep the load and has
known memory leak. On the other hand, in 7.5.5 it produces rare
records in the output file (say, 100 per minute). It looks like it
cannot match other records, but this is weird, as they are all in the
same format and happily match in lognormalize.
Maybe I've just found why is this. Different output modules seem to
be called in parallel in 7.5.5, and mmnormalize adopts output module
interface. Therefore, if mmnormalize is faster than omfile, then
omfile can see results of mmnormalize. But it is very unlikely.
Am I right? Is parser module interface better for message
modification modules?
actions take place in the order they are listed in the config file,
unless you define queues for the different actions, in which case they
just get copies to the queues, then each queue operates independantly.
so if you put mmnormalize in something with it's own queue, only that
queue will see the modified message
There should never be a race condition between modules.
_______________________________________________
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.
