pub trait Service: Fallback {
// Required methods
fn status(&self) -> LoggerStatus;
fn work(&self, msg: &Message) -> Result<(), ServiceError>;
fn as_any(&self) -> &dyn Any;
}Expand description
The Service trait defines the core execution logic for a logging backend.
A Service acts as the internal “Worker” or “Driver” sitting behind a LoggerImpl.
While the logger handles the frontend API and message queuing, the Service is responsible
for the actual side effects, such as disk I/O, network transmission, or database insertion.
§Hierarchy & Resilience
This trait extends Fallback. Every implementation must provide a mechanism to handle
messages that fail to be processed after the service’s internal retry logic has been exhausted.
§Threading Model
Implementations are typically executed within a dedicated background thread. Therefore,
any state held by a Service must be thread-safe (Send + Sync) to ensure
consistent behavior across the asynchronous boundary.
Required Methods§
Sourcefn status(&self) -> LoggerStatus
fn status(&self) -> LoggerStatus
Returns the current operational [LoggerStatus] of the service.
Sourcefn work(&self, msg: &Message) -> Result<(), ServiceError>
fn work(&self, msg: &Message) -> Result<(), ServiceError>
Processes a single Message.
§Arguments
msg- A reference to the Message to be processed.
§Returns
Ok(())if the message was handled successfully.Err(ServiceError)if an error occurred.
§Concurrency & Thread Safety
This method takes &self, meaning it can be called concurrently from
multiple threads if the LoggerImpl allows it.
[!NOTE] If the implementation requires modification of internal state (e.g., incrementing a counter or writing to a shared file), it must use Interior Mutability (e.g.,
AtomicU64,Mutex, ormpsc).