the essential behavior of this receiver (i.e., what it does with entries)
Closes the receiver.
Closes the receiver. This means that the resources held by this receiver should be released in preparation for it being decommissioned. This usually happens before system shutdown, but it does not necessarily mean that this receiver will not receive any more entries. Receviers can be closed simply to release file system or network resources.
This method must handle any flushing that is required prior to any resource deallocation. Timber will not
necessarily call flush()
before close()
.
the essential behavior of this receiver (i.e., what it does with entries)
the essential behavior of this receiver (i.e., what it does with entries)
Tells this receiver to flush any buffered entries that it has received but not yet fully processed.
Tells this receiver to flush any buffered entries that it has received but not yet fully processed. This makes it possible for this receiver to improve performance by batching I/O work.
Receives an Entry for processing.
Receives an Entry for processing. There is no initialization method for receivers, so this method must handle resource initialization on the first call after construction or after closure.
the entry being received by this receiver
A Receiver that allows the core behavior (what the receiver does) to be stacked with a BufferingPolicy and a ConcurrencyPolicy, provided by timber.
You can take advantage of the policy stacking in two ways. You can either create your receivers as extensions of Receiver and then instantiate them like this:
You can, alternatively extends StackableReceiver directly, in which case your instantiation code looks a bit nicer.
The downside is that your receiver can't be subclassed as easily. To get the best of both worlds, it may be wise to produce a pair of classes: one that extends Receiver and one that extends StackableReceiver.