| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
So far, the consumer was responsible for destroying objects. However, this
does not work well with ultra-reliable queues. This is the first move to
support them.
|
| |
|
|
| |
plus some cosmetic changes
|
| |
|
|
| |
... passed initial tests, but of course more are needed
|
| | |
|
| |
|
|
| |
... now that we know what we need from a theoretical POV.
|
| |\
| |
| |
| |
| | |
Conflicts:
runtime/rsyslog.h
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
- added $GenerateConfigGraph configuration command which can be used
to generate nice-looking (and very informative) rsyslog configuration
graphs.
- added $ActionName configuration directive (currently only used for
graph generation, but may find other uses)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
If the database rejected some entry, making the statement fail on it,
the batch was not cleaned and the same values were retried over and
over, causing a cascade of failures and a denial of service.
We use now OCI_BATCH_ERRORS so that everything valid in the batch is
inserted, and rejected values can be discarded.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of reading a complete line, we'll use a template and delegate
in the core to read such template. Then, all omoracle has to do is to
find that template and use it as the prepared statement.
I'm not sure if this is the correct approach, though. It has to dig
too much into rsyslog's structures...
txt_statement is stored in a private area, so that we don't mess too
much with rsyslog's internals (I still don't feel comfortable with
this much digging into template structures).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This directive controls the amount of memory needed for properties in
the batch. Users should specify the largest value they expect in the
statement. As per Rainer's comment:
on MAX_BUFSIZE: I'd tend to make this configurable, because with
RFC5424 messages can be much longer and RFC5425 now recommends a
minimum maximum size of 8K.
So we let users to choose. Maybe we need a sensible default value to
make users' lifes easier?
Also, the old non-vector based interface is not supported anymore. I
broke it already when moving to this stage.
|
| | |
| |
| |
| |
| | |
I'm not sure if GPLv3 contemplates the ability to link to proprietary
software, if it was previous work. I explicitly allow linking to OCI.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The action state machine now works correctly and has been verified a
few hand-picked cases. I am missing automatted tests, though, this is
not easy to achive... Anyhow, I've improved omtesting, so that it can
be used in such automatted tests.
|
| | |
| |
| |
| |
| | |
I am commiting it so that the code is visible, but will no begin
with the test environment.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
code is not complete, error cases are not handled.
|
| | | |
|
| | |
| |
| |
| |
| | |
... plus simplifying free() calls after agreement on mailing list
that we no longer need to check if the pointer is non-NULL
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
but rather inside on of the potentially many main msg queue worker
threads (an enhancement scheduled for all input plugins where this is
possible)
|
| | |
| |
| |
| | |
configuration directives
|
| |\| |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | |
|
| | | |\
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
runtime/queue.c
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
... badly affecting performance for delayable inputs (but not causeing
any other issues)
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem is that the rsyslog engine writes messages too quickly, so
that the queue never enters DA mode. We still have some look contemption.
One possible solution (hopefully) is to finally move the parser code out
of imtcp and onto the next thread. Need to address these issues first, then
come back to the test case.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... but the action consumer does not do anything really intelligent
with them. But the DA consumer is already done, as is the
main message queue consumer.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... but this code has serious problems when terminating the queue, also
it is far from being optimal. I will commit a series of patches (hopefully)
as I am on the path to the final implementation.
|
| |\| | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |\ \ \
| | |/ /
| |/| | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
... mostly removal of compile-time warnings (thanks to Michael
Biebl for suggesting to look after that)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
removed some warning in imklog compilation, but may not have
solved a lurking issue (but placed comment so that we know if
something surfaces)
|
| | | | | |
|
| | | | | |
|
| | | |\ \ |
|
| | |\ \ \ \
| | | |/ /
| | |/| /
| | |_|/
| |/| |
| | | |
| | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | | |
|
