On 03/31/15 15:49, Rainer Gerhards wrote:
That's because the presence of a queue triggers async behaviour: On
submit to the action queue, the message is duplicated and processed in
parallel (probably much later) to the original message. That parallel
/ async processing is the core reason you want a queue, and so this is
desired behavior. One can argue, though, if the action queue should
fail the action if the enqueue is not possible, but I am not sure if
that would be the right thing to do. Anyways, it's currently not
implemented.
Right, I was thinking that maybe the failure is propagated "up" through
the queue or the failure occurs only when the queue fills up and I've
tested for these, but as you say, that's not the current behavior. And,
admittedly, these are borderline usecases.
2015-03-31 14:01 GMT+02:00 Tomas Heinrich <thein...@redhat.com>:
If only the second action gains a queue and the first action fails, the one
with the queue is skipped and the next one without queue is activated.
That sounds strange and we should create a test case for it.
Is this the intended behavior?
Maybe action queues aren't meant to be used in this way; I haven't found any
mention of this in the docs or any warnings in the logs.
A warning is a very good idea!
The rsyslog version tested was v8.8.0.
The new-syntax equivalent seems to behave in the same way.
Let's have a look at the use case again: I think the appropriate
solution would be to have a ruleset with a ruleset queue, and have the
different failover locations inside that ruleset.
I agree completely. As these actions can be, in a way, considered as
one, having a single, shared queue is the most natural setup.
I didn't know whether you can achieve a similar behavior with just
action queues. I can see now why they don't fit.
That way, you have the async queue (so you de-couple from main
message flow), but you also have the benefit of sync action
processing for the failover actions.
Right, thanks for the explanation.
Tomas
_______________________________________________
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.
