| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
... when working with disk queues.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
... this is necessary in preparation for the final solution (we need
to have a "unified" writer). If it causes worse performance to have the
zip writher togehter with the synchronous write, we may do an async write...
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
(depending on configuration). This was a small change, but with big
results. There is more potential to explore, but the effects were so
dramatic that I think it makes sense to include this fix.
|
| |/
|
|
|
| |
... seems to work on quick testing, but needs a far more testing
and improvement. Good milestone commit.
|
| |
|
|
| |
Happend e.g. with imuxsock.
|
| |
|
|
|
| |
This could lead to timestamps written in the wrong format, but not to
an abort.
|
| |
|
|
|
|
| |
... hopefully reducing the number of allocs/frees as well as overall
memory usage in a busy system (plus that these shared properties hopefully
remain in cache longer than its single-instance counterparts...)
|
| |
|
|
|
|
| |
This sets stage to enable use of the property-interface to speed
up things (mildly), the next step to be done. I have also fixed one
regression of yesterday's changes.
|
| |
|
|
| |
... because LARGFILE macros were not defined consistenly
|
| |
|
|
|
|
|
|
|
|
|
| |
... plus a fix for a long-time bug in obj-types.h. That lead to
the object pointer only then to become NULL when the object was
actually destructed, I discovered this issue during
introduction of the pRcvFrom property in msg_t, but it potentially had other
effects, too. I am not sure if some experienced instability resulted from this
bug OR if its fix will cause harm to so-far "correctly" running code. The later
may very well be. Thus I will change it only for the current branch and also
the beta, but not in all old builds. Let's see how things evolve.
|
| |
|
|
|
| |
... plus some celanup and adding minor missing functionality
(the rule debug info again tell the property name, not just number).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
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.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... 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).
|
