| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
runtime/msg.c
runtime/queue.c
tools/syslogd.c
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
tools/syslogd.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This happened only on very high volume systems, if the same message was
being processed by two different actions. This was a regression caused
by the new config processor, which did no longer properly enable msg
locking in multithreaded cases. The bugfix is actually a refactoring of
the msg locking code - we no longer do unlocked operations, as the use
case for it has mostly gone away. It is potentially possible only at
very low-end systems, and there the small additional overhead of doing
the locking does not really hurt. Instead, the removal of that
capability can actually slightly improve performance in common cases,
as the code path is smaller and requires slightly less memory writes.
That probably outperforms the extra locking overhead (which in the
low-end case always happens in user space, without need for kernel
support as we can always directly aquire the lock - there is no
contention at all).
|
| | |
| | |
| | |
| | | |
v7 does not even have this code any longer
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
this was always action_t, but the initial design was more generic. We are
making it specific now in order to gain better performance (after all, we
did not need the generic engine in the past 8 years...)
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
doc/v7compatibility.html
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This was former the case after 1,000 failures and could cause rsyslog
to be spammed/ressou
|
| | | | |
|
|/ / / |
|
| | | |
|
|/ /
| |
| |
| |
| |
| | |
This still needs more optimizing as the call is very often
NOT needed - but we need to know about the templates in that
case.
|
| |
| |
| |
| | |
could lead to execution of not-to-be-executed action. very recent regression.
|
| | |
|
| |
| |
| |
| |
| | |
- removed no longer needed function
- debug log now contains action type for action objects
|
| | |
|
|\| |
|
| |\ |
|
| | |
| | |
| | |
| | | |
This most importantly could happen due to configuration errors.
|
| | | |
|
|/ /
| |
| |
| | |
This was not yet adapted to the new "active" structure.
|
| |
| |
| |
| |
| | |
NOTE: this is only compile-tested! For real testing, a module using
that mode is required. Will be done as next steps.
|
| |
| |
| |
| |
| |
| | |
This patch does NOT contain any implementation, this will happen
next. Thanks to Miloslav Trmac, who suggested a similar mode, which
I based the JSON idea on.
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
runtime/ruleset.c
tools/syslogd.c
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
action.c
configure.ac
doc/manual.html
runtime/ruleset.c
template.h
threads.c
tools/syslogd.c
|
| | |
| | |
| | |
| | | |
This is done to prevent name claches with libraries.
|
| | |\
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
|
| | | |
| | | |
| | | |
| | | | |
Thanks to Zdenek Salvet for finding this bug and to Bodik for reporting
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
configure.ac
|
| | | | |
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
runtime/rsyslog.h
|
| |\ \ \ |
|
| | | | | |
|
|\| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
configure.ac
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
this was an experiment in early v6 that did not work out. I forgot to
remove this code when I undid it.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Thanks to Abby Edwards for alerting us.
|
|/ / / / |
|
|\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| |\|
| | |
| | |
| | |
| | | |
Conflicts:
runtime/queue.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
even if there was a disk queue associated with it. The root cause of this
problem was that it makes no sense to delay messages once they arrive in the
action queue - the "input" that is being held in that case is the main
queue worker, what makes no sense.
Thanks to Marcin for alerting us on this problem and providing
instructions to reproduce it.
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
configure.ac
doc/manual.html
|
| | |\|
| | | |
| | | |
| | | |
| | | | |
Conflicts:
configure.ac
|
| | | | |
|
| |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
action.c
configure.ac
doc/imuxsock.html
doc/manual.html
runtime/queue.c
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
$MainMsgQueueLightDelayMark, $ActionQueueLightDelayMark; both
specify number of messages starting at which a delay happens.
|
| | | | |
|