This module blocks log messages and can be used to simulate a blocked route. When the module blocks the data flow, log messages are first accumulated in the buffers, and then the flow control mechanism pauses the input modules. Using the block() procedure, it is possible to programmatically stop or resume the data flow. It can be useful for real-world scenarios as well as testing. See the examples below. When the module starts, the blocking mode is disabled by default (it operates like pm_null would).
|To examine the supported platforms, see the list of installer packages in the Available Modules chapter.|
The pm_blocker module accepts only the common module directives.
The following functions are exported by pm_blocker.
Return TRUE if the module is currently blocking the data flow, FALSE otherwise.
The following procedures are exported by pm_blocker.
When mode is TRUE, the module will block. A
block(FALSE)should be called from a Schedule block or another module, it might not get invoked if the queue is already full.
In this example messages are received over UDP and forwarded to another host via TCP. The log data is forwarded during non-working hours (between 7pm and 8am). During working hours, the data is buffered on the disk.
<Input udp> Module im_udp ListenAddr 0.0.0.0:1514 </Input> <Processor buffer> Module pm_buffer # 100 MB disk buffer MaxSize 102400 Type disk </Processor> <Processor blocker> Module pm_blocker <Schedule> When 0 8 * * * Exec blocker->block(TRUE); </Schedule> <Schedule> When 0 19 * * * Exec blocker->block(FALSE); </Schedule> </Processor> <Output tcp> Module om_tcp Host 192.168.1.1:1514 </Output> <Route udp_to_tcp> Path udp => buffer => blocker => tcp </Route>