| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
The capability has been added for module to specify that they do not
like being unloaded.
related bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=222
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By implementing a trivial strlcpy it's much easier to detect string
truncations and react to them. This also gives a noticeable speedup in
buffer handling (can be HUGE), since strlcpy() doesn't clear all the
buffer entry before writing data.
Converted all uses of strncpy() into strlcpy().
Also, we don't need to check for some null pointers, as there are no
malloc-like operations in the doAction loop.
|
| |
|
|
|
| |
Tell which statement is failing, which element in the batch, and give
its details.
|
| |
|
|
| |
Improve traceability while testing.
|
| | |
|
| | |
|
| |
|
|
|
| |
Stop considering it as an error, and make it display the information
from the Oracle server.
|
| | |
|
| |
|
|
|
| |
call tryResume(), so we have to return RS_RET_SUSPENDED. Otherwise, we
may keep losing messages until rsyslog is restarted.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Instead of using the old-style configuration parameters, use
$... directives, which lead to simpler code, and also should make
user's configurations simpler. Needs some testing.
Currently, the supported directives are $OmoracleDB, $OmoracleDBUser
and $OmoracleDBPassword. $OmoracleDBStatement and $OmoracleDBBatchSize
may follow.
|
| | |
|
| |
|
|
|
| |
The core will call the action if tryResume succeeds, no need to make
it from here.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Emacs doesn't allow for proper indentation with rsyslog's macros (no
curly brackets, so it doesn't know where functions start), so I had to
manually add such indentation.
Add support for retrying actions, namely, disconnect from the DB,
re-connecting and re-executing the last prepared statement. Needs to
be tested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It now runs SQL statements given as templates. In this case, the
template is given on the configuration file and the core passes the
SQL statement correctly formatted to doAction. I still need to decide
how to structure this for having prepared statements (prepare them at
parseSelector time) and then make doAction to only bind arguments and
execute. It commits after each statement, which is awfully slow but
good enough for the moment.
Next step after that is have a buffer of arguments, and make doAction
store new data as it arrives, then run the statement only when the
buffer is almost full. Or something like that.
|
| |
|
|
|
|
| |
It will read and parse the config line (this code is not yet
rock-solid) and connect to the database at initialization time. I also
cleaned some debug messages that are not needed anymore.
|
| |
|
|
| |
This avoids crashes on initialization.
|
| |
|
|
|
|
|
| |
At this stage they are all empty, but at least it should be possible
to instantiate the module and perform some basic tests.
Fix some compilation warnings
|
| |
|
|
|
| |
Add configure option to build the oracle support, named
--enable-oracle and fix the Makefile.am accordingly.
|
|
|
Currently, resources are allocated, freed and the code compiles. No
tests yet.
|
