Module: AceMQ::AMQP::Patterns::ClaimCheckStore

Defined in:

lib/acemq/amqp/patterns/claim_check.rb

Overview

Where a payload too large for a broker actually goes.

A store is anything answering three methods:

put(content)  # stores bytes, returns the key the message will carry
get(key)      # the bytes, or nil when the store no longer holds them
delete(key)   # removes them

Three methods, so a store in front of S3, Azure Blob Storage, a filesystem or a database table is a small class. Nothing here knows about messaging: the store holds bytes under a key and hands them back, and ClaimCheckCodec is what turns that into a claim check on the wire.

A duck type rather than a class to inherit from, for the same reason as IdempotencyStore: the store somebody actually wants is their own object storage, and asking them to subclass something from a messaging library to get there is asking for the wrong thing.

Retention is the part that goes wrong

The store and the queue have different lifetimes, and nothing enforces a relationship between them. A message replayed a month later carries a key, and if the store expired that key the replay produces a message nobody can read — worse than a lost message, because it looks like a message and fails deep inside a consumer rather than visibly.

So the store's retention must exceed every retention that could bring a message back: queue TTLs, dead-letter queues, and however long somebody might sit on a message before replaying it by hand. When in doubt, longer.

An implementation is shared by every publisher and consumer on a connection, so it has to be safe to call from several threads.