| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
... this provides some basic support to integrate extensions that
are not direct parts of rsyslog to be built during its build
process.
|
| |
|
|\ |
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
|
| | |
| | |
| | |
| | | |
... as well as some other minor issues.
|
|\| |
| | |
| | |
| | |
| | | |
Conflicts:
tests/Makefile.am
|
| |\|
| | |
| | |
| | |
| | | |
Conflicts:
tests/Makefile.am
|
| | |
| | |
| | |
| | |
| | |
| | | |
specified.
Thanks to Michael Biebl for helping to debug this one.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The imdiag module now can very effectively inject messages, which also
frees us from uncertainties of tcp reception and processing. All shell
script based tests have been modularized, what makes it far easier to
create new tests. Also, the test bench now executes more reliable and
much faster, because we can now rely on actual engine information where
we previously did just a dumb sleep.
|
| | |
| | |
| | |
| | |
| | | |
which enables to talk to the rsyslog core at runtime. The current
implementation is only a beginning, but can be expanded over time
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Well, actually this and a lot of related things. I improved the
testbench so that the new capabilities are automatically tested and
also did some general cleanup. The current multiple tcp listener
solution will probably receive some further cleanup, too, but looks
quite OK so far. I also reviewed the way tcpsrv et all work, in
preparation of using this code for imdiag. I need to document the
findings, especially as the code is rather complicated "thanks" to
the combination of plain tcp and gssapi transport modes.
|
| | |
| | |
| | |
| | |
| | |
| | | |
imdiag was never finished (not even really begun), but now I need it.
I made the few things that are available compile, but more serious
work is required.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | | |
... 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)
|
|\| | |
|
| |\| |
|
| | |\ |
|
| | | |\ |
|
| | | | |\ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
this could cause loss of messages. The handling was correct if the
connection broke, but not if there was a problem with statement
execution. The most probable case for such a case would be invalid
sql inside the template, and this is now much easier to diagnose.
|
| | | | |\| |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- security bugfix: $AllowedSender was not honored, all senders were
permitted instead (see http://www.rsyslog.com/Article322.phtml)
(backport from v3-stable, v3.20.9)
- minor bugfix: dual close() call on tcp session closure
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
runtime/rsyslog.h
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Conflicts:
ChangeLog
runtime/rsyslog.h
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
... however, I did not not a test run due to the lack of
existing test drivers and the very low (aka "non-existing" interest
from the userbase in the feature).
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
which can be emittend when plugin can not load due to missing
core functionality.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Previous versions inserted garbage (the pointer was interpreted as the
string itself). It seems inserting arrays of strings is not that easy
with OCI.
This approach consumes 2KB per entry in the batch, so if you have
batches of size 1000 you'll be using 2MB for the batch. This size
doesn't change, anyways and the risk of leaking memory is gone. OCI
doesn't deal well with batches of strings. :(
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Let's hope it works.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Literal strings passed in the statement may contain ':', let's not
count them.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We'll receive a single statement to be prepared and a batch
size. Then, doAction will execute the statement only once per batch
hit, making the process much more efficient.
This will reduce network and DB server overhead. The downside is that
this version cannot be used with rsyslog v3 anymore. If anyone is
interested on backporting the module, they should choose all patches
up to this one.
Better documentation may follow.
|
|\| | | | | | | |
|
| |\ \ \ \ \ \ \
| | | |/ / / / /
| | |/| | | | |
| | | | | | | |
| | | | | | | | |
Conflicts:
ChangeLog
|
| | |\ \ \ \ \ \
| | | | |/ / / /
| | | |/| | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Conflicts:
ChangeLog
tcpsrv.c
tcpsrv.h
Note: we have a slight inconsistency, as interface version v4 was already
used for tcpsrv in this branch. We accept this inconsistency.
|
| | | |\ \ \ \ \
| | | | | |/ / /
| | | | |/| | |
| | | | | | | |
| | | | | | | | |
Conflicts:
ChangeLog
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This resulted in a fixed upper limit of 200 connections.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When rsyslog shuts down, we must send and commit any pending messages
or information will be lost. It will make rsyslog's shut down slower,
but also more reliable.
|
| | | | | | | | |
|
|/ / / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently, all statements to be executed are stored on the same
structure. When the batch size is reached, all statements are executed
in a single transaction, and then committed.
There are many corner cases in which an error may happen and the batch
may be left in an inconsistent state, perhaps leaking memory or
crashing. They will be fixed.
|
|\ \ \ \ \ \ \ |
|
| |\| | | | | | |
|
| |\ \ \ \ \ \ \ |
|