> In my opinion this may occur if messages came from different/concurrent > sources.
Depends on your environment. If you have a single UDP listener, reordering may occur on the wire before you even receive it. Sequence as seen on the input/API level is not sequence as the message may be originated. Not even so for local unix sockets, this is depending on scheduling order, which you cannot control in userland. So I can back David's point: it is dangerous to assume that a log stream has strict sequence. This may be the case for an single hop (obviously for messages within a single TCP stream), but not further than that. In general, you need to define an order relation. As a side note, a not-so-small part of the conference paper I am writing right now is about these wrong perception of log sequence that users commonly have. I think I can post it myself after the conference (this is the end of september timeframe). > But it should be possible to keep messages from the same > source in strict order (with performance loss). > > So again my question. Is it possible to force strict order of messages? I think you can come close to what you want: You need to dig into the queue docs. Set everything to single worker thread (maybe even use direct mode). If you use a recent build, set all batch sizes to one (this is conservative, in theory it should work with larger batches as well, iff everything is single-threaded). Note that when you use a disk assisted queue, the queue engine always puts some messages out of order when switching to/from Disk mode. Newer builds also consume messages from memory and disk concurrently and thus potentially out of queue order. So you need to avoid disk assisted mode. If you need disk functionality, use pure disk mode, only. Make sure you do not define more than one input per rsyslog instance. Else OS scheduling order for rsyslog threads (input vs. output) potentially gets you into trouble. Make sure you do not define any async output actions. Do not write to the same file (or action in general) from more than one action or more than one instance of rsyslog. That should give you a somewhat strict sequence of messages. Depending on the use case/volume, you'll see no to unacceptable performance loss. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
