On 11/17/2012 09:00 AM, Balazs Scheidler wrote:
dbparser: support inheriting properties in a corellation action
I merged this one, although I have some doubts. It uses log_msg_clone_cow(), which does have some tricky semantics, as it assumes that the cloned message will not change, once cloned.
I was thinking about removing clone_cow() completely because of this tricky stuff, and whenever we need a clone we're about to change the LogMessage anyway, and delaying the actual change means that we have to do two malloc() calls, instead of one.
Can you test whether changing the message that triggered the action with a rewrite rule, keeps the cloned one intact? This would need a parallel path to the db-parser(). It seems, that log_msg_clone_cow write protects the original log message, so trying to do a log_msg_set_value on the original message will result in an assertion. Sorry I didn't realize this when doing the original patch, explicitly copying all the name-value pairs seemed inefficient, but this behaviour is not desirable. Should I rework the patch this way or is there a better way of doing it?
Balint