This is not true for current master. It is here, as I suspect:
static rsRetVal
scriptExec(struct cnfstmt *root, batch_t *pBatch, sbool *active)
{
DEFiRet;
struct cnfstmt *stmt;
for(stmt = root ; stmt != NULL ; stmt = stmt->next) {
...
switch(stmt->nodetype) {
...
case S_CALL:
scriptExec(stmt->d.s_call.stmt, pBatch, active);
break;
This simple recursion does not allow for queuing.
Config and debug log below:
Ruleset(name="sub"
queue.type="FixedArray".
queue.size="200000".
queue.workerthreads="2"
queue.timeoutenqueue="0"
queue.dequeuebatchsize="1024"
) {
Action(
type="mmnormalize"
userawmsg="on"
rulebase="/usr/local/etc/rsyslog.d.norm/rules.rb"
)
Action (
type="omfile"
DynaFile="rawFilename2"
template="rawTemplate"
)
}
Ruleset(name="logd".
queue.type="FixedArray".
queue.size="200000".
queue.workerthreads="2"
queue.timeoutenqueue="0"
queue.dequeuebatchsize="1024"
){
call sub
set $!test = "999";
...
}
9911.174885257:7f9578db8700: imudp: epoll_wait() returned with 1 fds
9911.174941973:7f9578db8700: imudp: recvmmsg returned 1
9911.174971472:7f9578db8700: recv(3,157),acl:1,msg:<150>2013-11-01
12:08:23 ...
9911.174990486:7f9578db8700: imudp: recvmmsg returned -1
9911.175002142:7f9578db8700: logd: qqueueAdd: entry added, size now log
1, phys 1 entries
9911.175011008:7f9578db8700: logd:Reg: high activity - starting 1
additional worker thread(s).
9911.175081055:7f9578db8700: logd:Reg: started with state 0, num workers
now 1
9911.175090848:7f9578db8700: logd: MultiEnqObj advised worker start
9911.175104108:7f9577db6700: thread created, tid 28824, name 'rs:logd:Reg'
9911.175128571:7f9577db6700: DeleteProcessedBatch: we deleted 0 objects
and enqueued 0 objects
9911.175155708:7f9577db6700: doDeleteBatch: delete batch from store, new
sizes: log 1, phys 1
9911.175167624:7f9577db6700: msg parser: flags 70, from '~NOTRESOLVED~',
msg '<150>2013-11-01 12:08:23 ...'
9911.175176465:7f9577db6700: parse using parser list 0x17bb160 (the
default list).
9911.175186497:7f9577db6700: Parser 'rsyslog.rfc5424' returned -2160
9911.175198019:7f9577db6700: Message will now be parsed by the legacy
syslog parser (one size fits all... ;)).
9911.175213361:7f9577db6700: Parser 'rsyslog.rfc3164' returned 0
9911.175220455:7f9577db6700: processBatch: batch of 1 elements must be
processed
9911.175228151:7f9577db6700: scriptExec: batch of 1 elements, active
(nil), active[0]:1
9911.175263901:7f9577db6700: CALL [sub]
9911.175280548:7f9577db6700: scriptExec: batch of 1 elements, active
(nil), active[0]:1
9911.175287128:7f9577db6700: ACTION 0x17d3090
[mmnormalize:action(type="mmnormalize" ...)]
9911.175303283:7f9577db6700: RRRR: execAct [mmnormalize]: batch of 1
elements, active (nil)
9911.175316259:7f9577db6700: Called action(NotAllMark), processing
batch[0] via 'mmnormalize'
9911.175323900:7f9577db6700: Called action(Batch), logging to mmnormalize
9911.175332786:7f9577db6700: submitBatch: enter, nElem 1
9911.175339760:7f9577db6700: tryDoAction 0x17d3090, pnElem 1, nElem 1
9911.175347880:7f9577db6700: Action 0x17d3090 transitioned to state: itx
9911.175354858:7f9577db6700: entering actionCalldoAction(), state: itx
9911.175442747:7f9577db6700: Action 0x17d3090 transitioned to state: rdy
9911.175451948:7f9577db6700: action 0x17d3090 call returned 0
9911.175460819:7f9577db6700: scriptExec: batch of 1 elements, active
(nil), active[0]:1
9911.175467484:7f9577db6700: ACTION 0x17d9730
[builtin:omfile:action(type="builtin:omfile" ...)]
9911.175483056:7f9577db6700: RRRR: execAct [builtin:omfile]: batch of 1
elements, active (nil)
9911.175491175:7f9577db6700: Called action(NotAllMark), processing
batch[0] via 'builtin:omfile'
9911.175498109:7f9577db6700: Called action(Batch), logging to builtin:omfile
9911.175575796:7f9577db6700: submitBatch: enter, nElem 1
9911.175585036:7f9577db6700: tryDoAction 0x17d9730, pnElem 1, nElem 1
9911.175592618:7f9577db6700: Action 0x17d9730 transitioned to state: itx
9911.175599472:7f9577db6700: entering actionCalldoAction(), state: itx
9911.175606466:7f9577db6700: file to log to:
/srv/Temp/syslog/raw-201311021458.log2
9911.175613230:7f9577db6700: omfile: start of data: '<150>2013-11-01
12:08:23 ...'
9911.175777103:7f9577db6700: file stream raw-201311021458.log2 params:
flush interval 0, async write 0
9911.175845217:7f9577db6700: Added new entry 0 for file cache, file
'/srv/Temp/syslog/raw-201311021458.log2'.
9911.175855647:7f9577db6700: write to stream, pData->pStrm
0x7f95680017c0, lenBuf 389
9911.175864668:7f9577db6700: action 0x17d9730 call returned -2121
9911.175878491:7f9577db6700: strm 0x7f95680017c0: file
-1(raw-201311021458.log2) flush, buflen 389
9911.175887358:7f9577db6700: strmPhysWrite, stream 0x7f95680017c0, len 389
9911.175908678:7f9577db6700: file
'/srv/Temp/syslog/raw-201311021458.log2' opened as #6 with mode 416
9911.175933390:7f9577db6700: strm 0x7f95680017c0: opened file
'/srv/Temp/syslog/raw-201311021458.log2' for WRITE as 6
9911.175967795:7f9577db6700: strm 0x7f95680017c0: file 6 write wrote 389
bytes
9911.175977140:7f9577db6700: Action 0x17d9730 transitioned to state: rdy
9911.175987406:7f9577db6700: scriptExec: batch of 1 elements, active
(nil), active[0]:1
9911.175994479:7f9577db6700: SET !test =
9911.176007595:7f9577db6700: string '999'
9911.176028332:7f9577db6700: END SET
02.11.2013 14:48, Rainer Gerhards:
On Sat, Nov 2, 2013 at 11:43 AM, Pavel Levshin <[email protected]> wrote:
Hello.
Doc on call statement says:
The "call" statement can be used to call into any type of rulesets. If a
rule set has a queue assigned, the message will be posted to that queue and
processed asynchronously. Otherwise, the ruleset will be executed
synchronously and control returns to right after the call when the rule set
has finished execution.
Unfortunately, it is not true.
If it is not true for some versions, that's a bug.
Note that the ruleset parameters apply. If the ruleset has no queue (more
precisely: queue.type="direct" - the default), the ruleset itself is
synchronous.
Rainer
Called rulesets are executed synchronously, ever. Is it a degradation over
omruleset?
--
Pavel Levshin
31.10.2013 21:22, Rainer Gerhards:
Hi folks,
a word of warning: this module has been replaced by the "call" statement
and emits a warning message for quite a while. In some upcoming versions
(not 7.6) it will no longer by available inside the RPMs, but can still be
built from source.
Note that "call" is much more capable (and notably faster) than omruleset,
so it's probably a good idea to get rid of it if you still use it.
Rainer
______________________________**_________________
rsyslog mailing list
http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
______________________________**_________________
rsyslog mailing list
http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog>
http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/>
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
