[syslog-ng] merging stuff from merge-queue/3.4

[Balazs Scheidler]

----- Original message -----
> Balazs Scheidler <bazsi77 at gmail.com> writes:
> 
> > ----- Original message -----
> > > 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?
> > > 
> > 
> > I'd drop clone_cow() now, and implement a proper clone that allocates
> > the logmsg header and nvtable in a single block, and copies everything
> > through.
> > 
> > that way clone+change becomes cheaper and you got a clone call that
> > works in this case too.
> 
> There's another problem, though: pattern_db_process() also sets the
> original message write protected, so even if I do a proper clone, the
> original will remain write protected.

only in case it's stored in a correllation context.

> 
> I'm also a bit confused about the single block header + nvtable
> allocation...
> 
> I suppose I can do clone = log_msg_alloc(msg->payload->size), copy the
> header and the payload too and adjust clone->payload. Is that the
> correct way to do it?
> 

I can't really remember the code too much. double check whether there are pointer values, those would probably need adjustments.

also there are iv_list_heads used when a messagee is enqueued that need cleaning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20121122/b0cc1252/attachment.htm