summaryrefslogtreecommitdiffstats
path: root/runtime/queue.c
Commit message (Collapse)AuthorAgeFilesLines
* reduced number of debug messages a bit againRainer Gerhards2009-08-261-2/+0
|
* bugfix: discard action did not work (did not discard messages)Rainer Gerhards2009-07-301-0/+2
|
* cleanup & better debug message handlingRainer Gerhards2009-07-201-66/+65
| | | | | | the new handling will hopefully spare a few cycles, as function calls (and most importantly parameter generation!) or now only done when debug messages are actually active.
* corrected some conditions & one more simplificationRainer Gerhards2009-07-201-15/+3
|
* simplified startup of queue DA modeRainer Gerhards2009-07-201-64/+9
|
* solved potential race condition and some cleanupRainer Gerhards2009-07-201-6/+11
| | | | | | | code review brought up some few places where we may have run into a race. They have most probably been introduced during the recent set of changes. But I do not look at older versions because of the changed architecture, one can not simply backport this patch.
* bugfix: minor static memory leak while reading configurationRainer Gerhards2009-07-201-1/+0
| | | | | This did NOT leak based on message volume. Also, did some cleanup during the commit.
* architecture change: queue now always has at least one worker threadRainer Gerhards2009-07-201-17/+0
| | | | | | ...if not running in direct mode. Previous versions could run without any active workers. This simplifies the code at a very small expense. See v5 compatibility note document for more in-depth discussion.
* more cleanup/simplification (forgot to remove one mutex lock)Rainer Gerhards2009-07-201-11/+9
|
* some more threading changesRainer Gerhards2009-07-201-25/+21
| | | | ... as well as some cleanup
* further code simplificationRainer Gerhards2009-07-171-2/+1
| | | | | | | | | ... could even remove one mutex by using a better algorithm. I think I also spotted some situation in which a hang could have happened. As I can't fix it in v4 and less without moving to the new engine, I make no effort in testing this out. Hangs occur during shutdown, only (if at all). The code changes should also result in some mild performance improvement. Some bug potential, but overall the bug potential should have been greatly reduced.
* more code simplification, should also bring some performance enhancementRainer Gerhards2009-07-171-20/+18
| | | | reducing the number of thread cancellation state changes
* finishing touches for 5.1.2v5.1.2Rainer Gerhards2009-07-081-1/+1
|
* Merge branch 'v4-devel'Rainer Gerhards2009-07-081-99/+34
|\ | | | | | | | | | | Conflicts: runtime/debug.h runtime/stream.c
* | Merge branch 'v4-beta'Rainer Gerhards2009-07-071-2/+2
|\|
| * performance enhancement: much faster, up to twice as fastRainer Gerhards2009-07-061-2/+2
| | | | | | | | | | | | (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.
| * bugfix: subtle potential issue during queue shutdownRainer Gerhards2009-06-251-1/+1
| | | | | | | | | | ... this one could cause trouble, but I really don't think it caused any actual harm.
* | bugfix: subtle synchronization issueRainer Gerhards2009-06-251-9/+4
| | | | | | | | | | | | This may have caused a segfault under strange circumstances (but if we just run long enough with a high enough message volume, even the strangest circumstances will occur...)
* | added a few atomic operationsRainer Gerhards2009-06-251-9/+8
| | | | | | | | | | mostly to get thread debugger errors clean (plus, of course, it makes things more deterministic)
* | adapted (and improved) input batching to v5 engineRainer Gerhards2009-06-221-1/+2
| |
* | bugfix: huge memory leak in queue engineRainer Gerhards2009-06-221-0/+1
| | | | | | | | | | (made rsyslogd unusable in production). Occured if at least one queue was in direct mode (the default for action queues).
* | Merge branch 'omfile' into tmpRainer Gerhards2009-06-221-3/+121
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was a complex manual merge, especially in action.c. So if there occur some problems, this would be a good point to start troubleshooting. I run a couple of tests before commiting and they all went well. Conflicts: action.c action.h runtime/queue.c runtime/queue.h runtime/wti.c runtime/wti.h
| * removed uniprocessor optimizationRainer Gerhards2009-06-191-15/+0
| | | | | | | | | | | | ... 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).
| * some cleanupRainer Gerhards2009-06-161-6/+4
| |
| * implemented first version of multi-enqueue support, queue sideRainer Gerhards2009-06-161-0/+126
| |
* | Merge branch 'omfile' into v5-develRainer Gerhards2009-06-161-62/+68
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that this was NOT a trivial merge, and there may be some issues. This needs to be seen when we continue developing. Conflicts: runtime/msg.h runtime/obj.h runtime/queue.c runtime/srUtils.h runtime/stream.c runtime/stream.h runtime/wti.c tests/Makefile.am tools/omfile.c tools/syslogd.c
| * added capability to fsync() queue disk files for enhanced reliabilityRainer Gerhards2009-06-091-0/+5
| | | | | | | | | | | | | | also adds speed, because you do no longer need to run the whole file system in sync mode. New testbench and new config directives: - $MainMsgQueueSyncQueueFiles - $ActionQueueSyncQueueFiles
| * modified stream class and omfile to work with itRainer Gerhards2009-06-041-2/+1
| | | | | | | | now some basic operations are carried out via the stream class.
| * cleaned up stream class ...Rainer Gerhards2009-06-041-44/+46
| | | | | | | | | | | | ... and also made it callable via an rsyslog interface rather then relying on the OS loader (important if we go for using it inside loadbale modules, which we soon possible will)
* | some cleanup & fix make distcheckRainer Gerhards2009-05-281-14/+3
| |
* | some more fixes for queue engineRainer Gerhards2009-05-281-30/+37
| | | | | | | | The enhanced testbench now runs without failures, again
* | fixing an issue during DA mode queue shutdownRainer Gerhards2009-05-281-62/+46
| | | | | | | | | | also changed DA queue mode in that the regular workers now run concurrently.
* | preserving current changesRainer Gerhards2009-05-281-12/+23
| | | | | | | | | | | | ... in preparation for some larger changes - I need to apply some serious design changes, as the current system does not play well at all with ultra-reliable queues. Will do that in a totally new version.
* | interim commit: working on failure casesRainer Gerhards2009-05-271-103/+211
| | | | | | | | slightly improved situation, would like to save it before carrying on
* | solved design issue with queue terminationRainer Gerhards2009-05-261-95/+158
| | | | | | | | | | | | | | | | | | | | | | ... and also improved the test suite. There is a design issue in the v3 queue engine that manifested to some serious problems with the new processing mode. However, in v3 shutdown may take eternally if a queue runs in DA mode, is configured to preserve data AND the action fails and retries immediately. There is no cure available for v3, it would require doing much of the work we have done on the new engine. The window of exposure, as one might guess from the description, is very small. That is probably the reason why we have not seen it in practice.
* | free last processed message in all casesRainer Gerhards2009-05-201-10/+41
| | | | | | | | | | | | | | | | | | so far, the last processed message was only freed when the next one was processed. This has been changed now. More precisely, a better algorithm has been selected for the queue worker process, which also involves less overhead than the previous one. The fix for "free last processed message" as then more or less a side-effect (easy to do) of the new algorithm.
* | yield() no longer needed on uniproc thanks to new algorithmsRainer Gerhards2009-05-201-7/+0
| |
* | solved the intended-discard-during-dequeue issueRainer Gerhards2009-05-191-10/+12
| |
* | some cleanupRainer Gerhards2009-05-191-86/+0
| |
* | queue size calculation now based on logical/physical dequeueRainer Gerhards2009-05-191-48/+66
| | | | | | | | | | | | ... needed to split the old single counter into two. I wouldn't bet that I made some mistakes while doing so, but at least some ad-hoc tests plus the testbench do no longer indicate errors.
* | removed queue's UngetObj() callRainer Gerhards2009-05-181-99/+11
| | | | | | | | ... which is no longer needed thanks to the new queue design.
* | t-delete list implemented, queue store drivers updated...Rainer Gerhards2009-05-181-47/+306
| | | | | | | | | | | | ... on the way to the ultra-reliable queue modes (redesign doc). This version does not really work, but is a good commit point. Next comes queue size calculation. DA mode does not yet work.
* | moved user object destruction to queue itselfRainer Gerhards2009-05-131-3/+37
| | | | | | | | | | | | 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.
* | moving to a cleaner implementation of batchesRainer Gerhards2009-05-121-19/+30
| | | | | | | | ... now that we know what we need from a theoretical POV.
* | fixed abort condition in DA modeRainer Gerhards2009-04-231-2/+1
| |
* | fixing a small (newly-introduced) memory leakRainer Gerhards2009-04-231-10/+5
| | | | | | | | | | ... plus simplifying free() calls after agreement on mailing list that we no longer need to check if the pointer is non-NULL
* | added $MainMsgQueueDequeueBatchSize and $ActionQueueDequeueBatchSize ↵Rainer Gerhards2009-04-231-12/+10
| | | | | | | | configuration directives
* | Merge branch 'master' into multi-dequeueRainer Gerhards2009-04-231-4/+4
|\|
| * Merge branch 'v3-stable' into betaRainer Gerhards2009-04-231-6/+8
| |\ | | | | | | | | | | | | | | | Conflicts: ChangeLog runtime/queue.c
| | * bugfix: light and full delay watermarks had invalid valuesRainer Gerhards2009-04-231-6/+8
| | | | | | | | | | | | | | | ... badly affecting performance for delayable inputs (but not causeing any other issues)