On Tue, 3 Aug 2010, Steffen Sledz wrote: > Am 30.07.2010 14:52, schrieb Steffen Sledz: >> If a module always returns RS_RET_OK (like ompipe does) the actionDoRetry >> loop may not have leaved faked ACT_STATE_SUSP state in case iResumeOKinRow >> had ever reached a count of 1000. > > In our test the suggested patch seems to fix this problem. :) But now we hit > the next one. :( > > If we use a LinkedList DA-Queue for this channel suspended messages may be > transmitted out-of-order. This may not be a problem for database consumers. > But in our context this is really bad. > > Is this a bug or an intended behaviour?
intended behavior, the issue came up beforeand there are many different ways that messages can end up being processed out of order (including the network re-ordering UDP packets before they arrive) part of the huge performance advantage that rsyslog has is that it is able to use multiple threads to process messages (both inbound and outbound), trying to maintain the order would cripple rsyslog (and still not be good enough in many cases) when I took a class on the Simple Event Correlator (a very good tool for log analysis), the instructor had a specific example in the beginning to point out that you can't count on logs being processed by you in the order they are generated, and this was a couple of years ago before rsyslog started becoming so popular. This example was with plain old single-threaded syslogd. David Lang > Is it possible to force strict order of messages? > > Steffen > > _______________________________________________ > 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
