On Fri, 3 May 2013, Rainer Gerhards wrote:
tracking state between messages will require a major set of changes to
rsyslog internals (think of of problems like having multiple threads
processing messages and the need for them to start sharing state
information (potentially a LOT of state information)
Let me jump on that one (waited for the discussion). I think global
variables are not that hard, I just did not do them as I questioned if
there is any use case. In essence it just needs to have some separate
namespace.
Do you see use cases where this would make sense?
Setting variables that get used for other messages sounds useful, I can think of
several ways to use this (a simple one would be to tag if messages happen during
business hours or not, triggered by special log messages.
My main concern is around the locking needed to update such global variables
when there are lots of threads (and lots of global variables) around. Since we
are talking about variable length strings there is no way to do atomic updates,
so you will need to have reader and writer locks or some form of rcu to manage
the updates. Just the overhead of grabbing and releasing the read lock for each
message is enough overhead to be worried about, even when no updates happen.
Now, as always, I may be missing some trick that eliminates this worry, if so
I'd love to hear about it.
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.
