Trait hedwig::consume::Consumer[−][src]

pub trait Consumer {
    type AckToken: AcknowledgeToken;
    type Error;
    type Stream: Stream<Item = Result<AcknowledgeableMessage<Self::AckToken, ValidatedMessage>, Self::Error>>;
    fn stream(self) -> Self::Stream;

    fn consume<M>(
        self, 
        decoder: M::Decoder
    ) -> MessageStream<Self::Stream, M::Decoder, M>
    where
        Self: Sized,
        M: DecodableMessage,
    { ... }
}
This is supported on crate feature consume only.
Expand description

Message consumers ingest messages from a queue service and present them to the user application as a Stream.

Message Decoding

Messages pulled from the service are assumed to have been created by some hedwig publisher and therefore were validated against the included schema when publishing. It is the decoder’s responsibility (when provided to functions like consume) to check this schema and the accompanying payload for validity.

Acknowledging Messages

Typically message services deliver messages with a particular delivery time window, during which this message won’t be sent to other consumers. In AWS SQS this is called the visibility timeout, and in GCP PubSub this is the ack deadline.

If a message is successfully acknowledged within this time, it will be considered processed and not delivered to other consumers (and possibly deleted depending on the service’s configuration). A message can conversely be negatively-acknowledged, to indicate e.g. processing has failed and the message should be delivered again to some consumer. This time window can also be modified for each message, to allow for longer or shorter message processing than the default configured time window.

Implementations of this trait do not ack/nack/modify messages themselves, and instead present this functionality to users with the AcknowledgeableMessage type. Message processors are responsible for handling message acknowledgement, including extensions for processing time as necessary.

Bear in mind that message delivery and acknowledgement are all best-effort in distributed message services. An acknowledged or extended message may still be re-delivered for any number of reasons, and applications should be made resilient to such events.

Associated Types

The type of acknowledgement tokens produced by the underlying service implementation

Errors encountered while streaming messages

The stream returned by stream

Required methods

Begin pulling messages from the backing message service.

The messages produced by this stream have not been decoded yet. Users should typically call consume instead, to produce decoded messages.

Provided methods

Create a stream of decoded messages from this consumer, using a decoder for the given decodable message type.

Implementors