| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
some things inside the message can be used over a large number of
messages and need to to be allocated and re-written every time. I now
begin to implement this as a "prop_t" object, first use for the inputName.
Some input modules are already converted, some others to go. Will do
a little performance check on the new method before I go further.
Also, this commit has some cleanup and a few bug fixes that prevented
compiliation in debug mode (I overlooked this as I did not compile
for debug, what I normally do, and the automatted test also does not
do that)
|
|\
| |
| |
| |
| | |
Conflicts:
tools/syslogd.c
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
stderr/stdout were not closed to be able to emit error messages,
but this caused ssh sessions to hang. Now we close them after the
initial initialization. See forum thread:
http://kb.monitorware.com/controlling-terminal-issues-t9875.html
|
| | |
| | |
| | |
| | |
| | | |
the deferred activation of input modules broke part of the testbench -
but this was a testbench issue, not one of the patch
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | |
|
| | |
| | |
| | |
| | | |
inline
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
... but I don't see the name anywhere...?
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
... this one could cause trouble, but I really don't think it caused
any actual harm.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- bugfix: subtle (and usually irrelevant) issue in timout processing
timeout could be one second too early if nanoseconds wrapped
- set a more sensible timeout for shutdow, now 1.5 seconds to complete
processing (this also removes those cases where the shutdown message
was not written because the termination happened before it)
|
| | |
| | |
| | |
| | |
| | | |
... as far as I think this mostly is to keep the thread debuggers
happy
|
|\| | |
|
| |\| |
|
| | |\ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Detected under threading debugger, seems not to have any impact on
actual deployments.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
this bug was introduced by a recent change which was a bit too agressive
in avoiding locking. We can probably do better than with this patch, but
I think I'll move that into the v5 engine.
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Conflicts:
ChangeLog
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
the string area that is used to build the string being passed to
the output module is now part of the action structure. As such,
access to it must also be guarded by the action mutex (an even more
optimal solution may be to store it in thread-local storage, but
there always must remain some room for improvement ;)).
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... hopefully removes false positives (but may cause some trouble
with hostname parsing). For details, see this bug tracker:
http://bugzilla.adiscon.com/show_bug.cgi?id=126
This patch is not optimal for v4 - another one will follow. The spirit
of this commit is to enable easier backporting if someone is interested
in doing so.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- done malloc() instead of calloc() for msg_t, as we have large space
which needs not be initialized
- shrunk syslogTime structure in the hope to get better cache and
write performance (non-aligned data should not hurt much here)
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Testing has shown that at least the glibc malloc() subsystem returns
memory to the OS far too late in our case. So we need to help it a bit,
by calling malloc_trim(), which will tell the alloc subsystem
to consolidate and return to the OS.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
we usually stay long enough inside the actions, so there should be
no problem with reaching a cancellation point. Actually, if we
really need to cancel, the thread is in an output action (otherwise
it would have willingly terminated).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... as it was not even optimal on uniprocessors any longer ;) I keep
the config directive in, maybe we can utilize it again at some later
point in time (questionable).
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
tests for the various timestamp formats have been added
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
this was a regression I introduced this afternoon
|
| | | |
| | | |
| | | |
| | | |
| | | | |
WARNING: currently, message repeation processing is disabled, must
be reenabled (but prefer to do some other tests first)
|
| | | | |
|